Dukungan versi kamera

Halaman ini menjelaskan perbedaan versi dalam Camera HAL, API, dan Pengujian Compatibility Test Suite (CTS). Materi ini juga mencakup beberapa perubahan arsitektural yang dibuat untuk memperkuat dan mengamankan framework kamera di Android 7.0, peralihan ke Treble di Android 8.0, dan pembaruan yang harus dilakukan vendor mendukung perubahan ini dalam implementasi kamera mereka.

Terminologi

Istilah berikut digunakan di halaman ini:

Camera API1

Framework kamera tingkat aplikasi di perangkat Android 4.4 dan yang lebih lama, ditampilkan melalui class android.hardware.Camera.

Camera API2

Framework kamera tingkat aplikasi di perangkat Android 5.0 dan yang lebih tinggi, ditampilkan melalui paket android.hardware.camera2.

HAL Kamera

Lapisan modul kamera yang diimplementasikan oleh vendor SoC. Publik tingkat aplikasi dibangun di atas HAL kamera.

Kamera HAL3.1

Versi HAL perangkat kamera yang dirilis dengan Android 4.4.

Kamera HAL3.2

Versi HAL perangkat kamera yang dirilis dengan Android 5.0.

CTS API1 Kamera

Rangkaian uji CTS kamera yang dijalankan di atas Kamera API1.

CTS API2 Kamera

Kumpulan uji CTS kamera tambahan yang dijalankan di atas Camera API2.

Treble

Memisahkan implementasi vendor (software khusus perangkat, level lebih rendah untuk perangkat tertentu) yang ditulis oleh produsen silicon) dari framework Android OS melalui antarmuka vendor.

HIDL

Bahasa definisi antarmuka HAL diperkenalkan dengan Treble dan digunakan untuk menentukan antarmuka antara HAL dan para penggunanya.

VTS

Suite pengujian vendor diperkenalkan bersama Treble.

Camera API

Android menyertakan API kamera berikut.

Camera API1

Android 5.0 sudah tidak menggunakan lagi Camera API1, dan akan terus dihentikan sebagai versi baru pengembangan platform berfokus pada Camera API2. Namun, periode penghentian bertahap panjang, dan rilis Android akan terus mendukung aplikasi Camera API1 untuk beberapa saat. Secara khusus, dukungan akan terus berlanjut untuk:

• Antarmuka Camera API1 untuk aplikasi. Aplikasi kamera yang dibuat di atas Kamera API1 seharusnya berfungsi seperti biasa pada perangkat yang menjalankan versi rilis Android yang lebih rendah.
• Versi Camera HAL. Termasuk dukungan untuk Kamera HAL1.0.

Camera API2

Framework Camera API2 mengekspos kontrol kamera tingkat rendah ke aplikasi, termasuk alur burst/streaming zero-copy yang efisien dan kontrol per frame eksposur, penambahan, penambahan white balance, konversi warna, denoise, mempertajam, dan lain-lain. Untuk mengetahui detailnya, tonton Ringkasan video Google I/O.

Android 5.0 dan yang lebih tinggi menyertakan Camera API2; Namun, perangkat yang menjalankan Android 5.0 dan yang lebih tinggi mungkin tidak mendukung semua fitur Camera API2. Tujuan Properti android.info.supportedHardwareLevel yang dapat dikueri aplikasi antarmuka Camera API2 melaporkan salah satu dukungan berikut level:

• LEGACY: Perangkat ini mengekspos kemampuan ke aplikasi melalui Antarmuka Camera API2 yang kurang lebih memiliki kemampuan yang sama terekspos ke aplikasi melalui antarmuka Camera API1. Kode framework lama secara konseptual menerjemahkan panggilan Camera API2 menjadi panggilan Camera API1; perangkat lama tidak mendukung fitur Camera API2 seperti kontrol per bingkai.
• LIMITED: Perangkat ini mendukung beberapa kemampuan Camera API2 (tetapi tidak semua) dan harus menggunakan Camera HAL 3.2 atau yang lebih baru.
• FULL: Perangkat ini mendukung semua kemampuan utama Camera API2 dan harus menggunakan Camera HAL 3.2 atau yang lebih tinggi dan Android 5.0 atau yang lebih tinggi.
• LEVEL_3: Perangkat ini mendukung pemrosesan ulang YUV dan gambar RAW rekam, bersama dengan konfigurasi aliran output tambahan.
• EXTERNAL: Perangkat ini mirip dengan LIMITED perangkat dengan beberapa pengecualian; misalnya, beberapa informasi sensor atau lensa tidak dilaporkan atau memiliki kecepatan frame yang kurang stabil. Level ini digunakan untuk eksternal seperti webcam USB.

Kemampuan individu diekspos melalui Properti android.request.availableCapabilities di Camera API2 antarmuka. Perangkat FULL memerlukan MANUAL_SENSOR dan Kemampuan MANUAL_POST_PROCESSING, di antaranya. Tujuan Kemampuan RAW bersifat opsional bahkan untuk perangkat FULL. LIMITED perangkat dapat mengiklankan subkumpulan kemampuan ini, tidak termasuk satu pun. Namun, kemampuan BACKWARD_COMPATIBLE harus selalu didefinisikan.

Level hardware perangkat yang didukung, serta Kamera tertentu Kemampuan API2 yang didukungnya, tersedia sebagai tanda fitur berikut untuk mengizinkan pemfilteran Google Play untuk aplikasi kamera Camera API2.

• android.hardware.camera.hardware_level.full
• android.hardware.camera.capability.raw
• android.hardware.camera.capability.manual_sensor
• android.hardware.camera.capability.manual_post_processing

Persyaratan CTS

Perangkat yang menjalankan Android 5.0 dan yang lebih tinggi harus lulus Camera API1 CTS, Camera Uji kamera API2 CTS dan CTS Verifier.

Perangkat yang tidak menampilkan implementasi Camera HAL3.2 dan tidak mampu mendukung antarmuka Camera API2 lengkap tetap harus meneruskan respons Tes CTS API2. Namun, perangkat berjalan di Camera API2 Mode LEGACY (saat panggilan Camera API2 dipetakan secara konseptual untuk panggilan Camera API1) sehingga setiap tes CTS Camera API2 yang terkait dengan fitur atau di luar Camera API1 otomatis dilewati.

Pada perangkat lama, uji CTS Camera API2 yang dijalankan menggunakan antarmuka dan kemampuan Camera API1 publik yang ada tanpa lainnya. Bug yang terekspos (dan yang menyebabkan kegagalan CTS Camera API2) adalah {i>bug<i} yang sudah ada di Camera HAL yang ada di perangkat, dan dengan demikian ditemukan oleh aplikasi Camera API1 yang sudah ada. Kami kira tidak banyak serangga seperti ini (tetapi, bug semacam ini harus diperbaiki agar lulus uji CTS API2 Kamera).

Persyaratan VTS

Perangkat yang menjalankan Android 8.0 dan yang lebih tinggi dengan implementasi HAL terbinder harus lewati Kamera Pengujian VTS.

Hardening framework kamera

Untuk memperkuat keamanan framework media dan kamera, Android 7.0 menggerakkan kamera keluar dari server media. Mulai Android 8.0, setiap Kamera yang di-binder HAL berjalan dalam proses yang terpisah dari layanan kamera. Vendor mungkin perlu membuat perubahan di HAL kamera tergantung pada versi API dan HAL yang digunakan. Tujuan bagian berikut merinci perubahan arsitektur dalam AP1 dan AP2 untuk HAL1 dan HAL3, serta persyaratan umum.

Perubahan arsitektur untuk API1

Perekaman video API1 dapat mengasumsikan encoder kamera dan video live pada {i>checkout<i}. Saat menggunakan API1 di:

• HAL3, di mana layanan kamera menggunakan BufferQueue untuk meneruskan buffer antara proses, tidak ada pembaruan vendor yang diperlukan.

  

  Gambar 1. Kamera dan media Android 7.0 ditumpuk di API1 pada HAL3

• HAL1, yang mendukung penerusan metadata dalam buffer video, vendor harus mengupdate HAL untuk menggunakan kMetadataBufferTypeNativeHandleSource. (kMetadataBufferTypeCameraSource tidak lagi didukung di Android 7.0.)

  

  Gambar 2. Kamera dan media Android 7.0 stack di API1 pada HAL1

Perubahan arsitektur untuk API2

Untuk API2 di HAL1 atau HAL3, BufferQueue meneruskan buffer sehingga jalur tersebut berlanjut ke tempat kerja. Arsitektur Android 7.0 untuk API2 pada:

• HAL1 tidak terpengaruh oleh pemindahan layanan kamera, dan tidak ada vendor update diperlukan.
• HAL3 terpengaruh, tetapi tidak ada update vendor diperlukan:

  

  Gambar 3. Kamera dan media Android 7.0 stack di API2 pada HAL3

Persyaratan tambahan

Perubahan arsitektur yang dibuat untuk hardening media dan framework kamera keamanan mencakup persyaratan perangkat tambahan berikut.

• Umum. Perangkat memerlukan bandwidth tambahan karena IPC, yang dapat memengaruhi kasus penggunaan kamera yang sensitif terhadap waktu, seperti video berkecepatan tinggi rekaman. Vendor dapat mengukur dampak sebenarnya dengan menjalankan android.hardware.camera2.cts.PerformanceTest dan Google Kamera untuk perekaman video berkecepatan tinggi 120/240 FPS. Perangkat juga memerlukan sejumlah kecil RAM tambahan untuk membuat proses baru.
• Meneruskan metadata dalam buffer video (khusus HAL1). Jika HAL1 menyimpan metadata dan bukan data {i>frame<i} YUV yang sebenarnya dalam {i>buffer<i} video, HAL harus menggunakan kMetadataBufferTypeNativeHandleSource sebagai buffer metadata ketik dan teruskan VideoNativeHandleMetadata dalam buffer video. (kMetadataBufferTypeCameraSource tidak lagi didukung di Android 7.0.) Dengan VideoNativeHandleMetadata, framework kamera dan media dapat melewati buffer video antarproses dengan menserialisasi dan melakukan deserialisasi penanganan native dengan benar.
• Alamat handle buffer tidak selalu menyimpan buffer yang sama (Khusus HAL3). Untuk setiap permintaan pengambilan, HAL3 mendapatkan alamat buffer nama sebutan channel. HAL tidak dapat menggunakan alamat untuk mengidentifikasi {i>buffer<i} karena alamatnya dapat menyimpan handle buffer lain setelah HAL mengembalikan buffer. Anda harus memperbarui HAL untuk menggunakan {i>buffer <i} untuk mengidentifikasi buffer. Misalnya, HAL menerima alamat A {i>buffer<i} (menangani penyangga), yang menyimpan tuas {i>buffer<i} A. Setelah HAL kembali menangani buffer A, alamat buffer A dapat menyimpan handle buffer B HAL menerimanya.
• Memperbarui kebijakan SELinux untuk server kamera. Jika kebijakan SELinux khusus perangkat memberikan izin server media untuk menjalankan kamera, Anda harus memperbarui kebijakan SELinux untuk memberikan izin yang tepat ke server kamera. Rab tidak menyarankan replikasi kebijakan SELinux server media untuk server kamera (karena server media dan server kamera umumnya memerlukan sumber daya yang berbeda sistem). Server kamera hanya boleh memiliki izin yang diperlukan untuk menjalankan kamera fungsi dan izin terkait kamera yang tidak diperlukan di server media harus dihapus.
• Pemisahan antara Camera HAL dan server kamera. Android 8.0 dan yang lebih tinggi juga memisahkan HAL Kamera binderisasi dalam suatu proses berbeda dari cameraserver. IPC melewati Antarmuka yang ditentukan HIDL.

Validasi

Untuk semua perangkat yang menyertakan kamera dan menjalankan Android 7.0, verifikasi dengan menjalankan Android 7.0 CTS. Meskipun Android 7.0 tidak menyertakan tes CTS baru yang memverifikasi perubahan layanan kamera, uji CTS yang ada gagal jika Anda belum melakukan pembaruan yang ditunjukkan di atas.

Untuk semua perangkat yang menyertakan kamera dan menjalankan Android 8.0 dan yang lebih baru, verifikasi implementasi vendor dengan menjalankan VTS.

Histori versi Camera HAL

Untuk daftar pengujian yang tersedia untuk mengevaluasi Android Camera HAL, lihat Pengujian HAL Kamera Checklist.

Android 10

Android 10 memperkenalkan update berikut.

Camera API

• Peningkatan multi-kamera yang memungkinkan kamera fisik untuk digunakan secara terpisah atau melalui kamera logis yang sesuai dengan menyembunyikan ID kamera fisik. Lihat Dukungan Multi-Kamera.
• Kemampuan untuk memeriksa apakah konfigurasi sesi tertentu tidak didukung tanpa overhead performa pembuatan sesi baru. Lihat CameraDevice
• Kemampuan untuk mengambil konfigurasi streaming yang direkomendasikan untuk penggunaan tertentu untuk membuat klien lebih hemat daya dan berperforma tinggi. Lihat getRecommendedStreamConfigurationMap
• Dukungan untuk format gambar JPEG depth. Untuk mengetahui detail selengkapnya, lihat Spesifikasi Dynamic Depth.
• Dukungan untuk Format Image HEIC. Lihat Pencitraan HEIF.
• Peningkatan privasi. Kunci tertentu diperlukan untuk klien untuk memiliki CAMERA sebelum dapat diambil CameraCharacteristics. Lihat getKeysNeedingPermission.

HAL Kamera

Versi Camera HAL berikut diupdate di Android 10.

3,5

ICameraDevice

• getPhysicalCameraCharacteristics: Informasi kamera statis untuk ID kamera fisik yang mendukung objek logis perangkat kamera utama. Lihat Dukungan Multi-Kamera.
• isStreamCombinationSupported: Metode ini mendukung objek publik API yang membantu klien melakukan kueri jika konfigurasi sesi didukung. Lihat API untuk mengkueri kombinasi aliran data.

ICameraDeviceSession

• isReconfigurationNeeded: Metode yang memberi tahu framework kamera apakah streaming selesai konfigurasi ulang diperlukan untuk kemungkinan nilai parameter sesi baru. Ini membantu menghindari penundaan konfigurasi ulang kamera yang tidak perlu. Lihat Kueri konfigurasi ulang sesi.
• HALAMAN buffer management API: API ini memungkinkan HAL kamera untuk meminta buffer dari framework kamera hanya jika diperlukan, bukan menggabungkan menangkap permintaan dengan buffer terkait di seluruh pipeline kamera, yang berpotensi menghemat memori secara signifikan.
  • signalStreamFlush: Memberi sinyal ke HAL bahwa kamera layanan akan menjalankan configureStreams_3_5 dan HAL harus mengembalikan semua{i> buffer<i} aliran yang ditentukan.
  • configureStreams_3_5: Mirip dengan ICameraDevice3.4.configureStreams, tetapi dalam selain itu, penghitung streamConfigCounter disediakan untuk memeriksa kondisi race antara configureStreams_3_5 dan panggilan signalStreamFlush.

Update untuk ICameraDeviceCallback:

• requestStreamBuffers: Callback sinkron yang dipanggil HAL kamera untuk meminta izin server kamera {i>buffer<i} (penyangga). Lihat requestStreamBuffers.
• returnStreamBuffers: Callback sinkron untuk HAL kamera guna mengembalikan buffer output ke kamera. Lihat returnStreamBuffers.

3,4

Kunci berikut ditambahkan ke metadata kamera di Android 10.

• Format gambar
  • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
  • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
  • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
• Tag metadata kamera
  • 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
• Kapabilitas
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
• Nilai untuk ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT tombol
  • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
  • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
• Konfigurasi streaming kedalaman dinamis yang tersedia
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
  • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
• Konfigurasi streaming HEIC yang tersedia
  • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
  • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Modul kamera

Versi modul kamera berikut diupdate di Android 10.

2,5

• Menambahkan metode notifyDeviceStateChange yang akan digunakan perangkat untuk memberi tahu HAL kamera ketika perubahan fisik, seperti lipatan, memengaruhi kamera dan {i>routing<i}.

2,4

• Perangkat yang diluncurkan dengan level API 29 atau yang lebih tinggi HARUS melaporkan true untuk isTorchModeSupported.

Android 9

Rilis Android 9 memperkenalkan update berikut pada API2 kamera dan Antarmuka HAL.

Camera API

• Memperkenalkan API multi-kamera untuk mendukung perangkat yang lebih baik dengan kamera menghadap ke arah yang sama, memungkinkan fitur seperti bokeh dan zoom yang mulus. Hal ini memungkinkan aplikasi melihat beberapa kamera di perangkat sebagai satu kesatuan unit logis (kamera logis). Permintaan pengambilan juga dapat dikirim ke perangkat kamera yang mencakup satu kamera logis. Lihat Dukungan Multi-Kamera.
• Memperkenalkan parameter sesi. Parameter sesi adalah subset dari parameter penangkapan yang dapat menyebabkan penundaan pemrosesan yang berat ketika diubah. Biaya ini dapat dimitigasi jika klien meneruskan nilai awal mereka selama inisialisasi sesi pengambilan. Lihat Parameter Sesi.
• Menambahkan kunci data stabilisasi optik (OIS) untuk stabilisasi tingkat aplikasi dan yang dihasilkan. Lihat STATISTICS_OIS_SAMPLES.
• Menambahkan dukungan flash eksternal. Lihat CONTROL_AE_MODE_ON_EXTERNAL_FLASH.
• Menambahkan intent pelacakan gerakan di CAPTURE_INTENT. Lihat CONTROL_CAPTURE_INTENT_MOTION_TRACKING.
• Menghentikan penggunaan LENS_RADIAL_DISTORTION dan menambahkan LENS_DISTORTION sebagai penggantinya.
• Menambahkan mode koreksi distorsi di CaptureRequest. Lihat DISTORTION_CORRECTION_MODE.
• Menambahkan dukungan untuk kamera USB/UVC eksternal pada perangkat yang didukung. Lihat INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

HAL Kamera

3,4

Update untuk ICameraDeviceSession

• configureStreams_3_4: Menambahkan dukungan untuk sessionParameters dan kamera logis.
• processCaptureRequest_3_4: Menambahkan dukungan untuk menyertakan ID kamera fisik dalam struktur streaming.

Update untuk ICameraDeviceCallback

• processCaptureResult_3_4: Menambahkan metadata kamera fisik dalam hasil pengambilan gambar.

3,3

Tombol berikut ditambahkan ke metadata kamera di Android 9.

• Kapabilitas
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
  • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
• Tag metadata kamera
  • 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

Rilis Android 8.0 memperkenalkan Treble. Dengan Treble, vendor Camera HAL implementasinya harus binderized. Android 8.0 juga berisi penyempurnaan utama berikut untuk layanan Kamera:

• Platform bersama: Memungkinkan beberapa platform yang berbagi platform yang sama OutputConfiguration
• System API untuk mode kamera kustom
• onCaptureQueueEmpty

Lihat bagian di bawah untuk informasi selengkapnya tentang fitur ini.

Platform bersama

Fitur ini memungkinkan hanya satu set buffer untuk menjalankan dua output, seperti pratinjau, dan encoding video, yang akan mengurangi daya dan konsumsi memori. Kepada mendukung fitur ini, produsen perangkat perlu memastikan HAL kamera Implementasi HAL gralloc dapat membuat {i> buffer <i}gralloc yang digunakan oleh konsumen yang berbeda (seperti komposer hardware/GPU dan video encoder), bukan hanya satu konsumen. Layanan kamera meneruskan penanda penggunaan konsumen ke HAL kamera dan HAL gralloc; mereka perlu mengalokasikan jenis {i>buffer<i} yang tepat, atau kamera HAL perlu mengembalikan bahwa kombinasi konsumen ini tidak didukung.

Lihat enableSurfaceSharing dokumentasi developer untuk detail tambahan.

System API untuk mode kamera kustom

API kamera publik menentukan dua mode operasi: normal dan dibatasi perekaman berkecepatan tinggi. Keduanya memiliki semantik yang cukup berbeda; misalnya, mode kecepatan tinggi dibatasi maksimal hingga dua output tertentu sekaligus. Bervariasi OEM telah menyatakan minatnya untuk mendefinisikan mode kustom lainnya untuk kemampuan khusus hardware. Di balik layar, mode tersebut hanyalah bilangan bulat diteruskan ke configure_streams. Lihat: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams.

Fitur ini meliputi panggilan API sistem yang dapat digunakan aplikasi kamera OEM untuk mengaktifkan mode kustom. Mode ini harus dimulai pada nilai integer 0x8000 untuk menghindari dengan mode mendatang yang ditambahkan ke API publik.

Untuk mendukung fitur ini, OEM hanya perlu menambahkan mode baru ke HAL mereka, dipicu oleh integer ini yang diteruskan ke HAL pada configurations_streams, dan kemudian aplikasi kamera kustom mereka menggunakan API sistem.

Nama metodenya adalah android.hardware.camera2.CameraDevice#createCustomCaptureSession. Lihat: frameworks/base/core/java/android/hardware/camera2/CameraDevice.

onCaptureQueueEmpty

Tujuan API ini adalah untuk mengurangi latensi perubahan kontrol seperti zoom sebesar menjaga agar antrean permintaan sekosong mungkin. onCaptureQueueEmpty tidak memerlukan pekerjaan HAL; itu sepenuhnya merupakan tambahan sisi kerangka kerja. Aplikasi yang ingin memanfaatkannya, Anda perlu menambahkan pemroses ke callback tersebut dan merespons dengan tepat. Umumnya itu adalah dengan mengirim permintaan pengambilan lain ke kamera perangkat seluler.

Antarmuka HIDL kamera

Antarmuka HIDL Kamera adalah perbaikan menyeluruh antarmuka HAL Kamera yang menggunakan API stabil yang didefinisikan HIDL. Semua fitur dan kemampuan kamera diperkenalkan dalam versi lama versi 3.4 dan 2.4 terbaru (untuk kamera ) juga merupakan bagian dari definisi HIDL.

3.4

Sedikit tambahan pada metadata yang didukung dan perubahan pada dukungan data_space:

• Tambahkan metadata statis ANDROID_SENSOR_OPAQUE_RAW_SIZE sebagai wajib jika format RAW_OPAQUE didukung.
• Tambahkan ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE statis metadata sebagai wajib jika format RAW apa pun didukung.
• Alihkan kolom camera3_stream_t data_space ke yang lebih fleksibel definisi sebelumnya, dengan menggunakan definisi encoding ruang data versi 0.
• Penambahan metadata umum yang dapat digunakan untuk HALv3.2 atau yang lebih baru:
  • 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

Revisi kecil dari HAL kemampuan yang diperluas:

• Update API pemrosesan ulang OPAQUE dan YUV.
• Dukungan dasar untuk buffer output kedalaman.
• Penambahan kolom data_space ke camera3_stream_t.
• Penambahan bidang rotasi ke camera3_stream_t.
• Penambahan mode operasi konfigurasi streaming camera3 ke camera3_stream_configuration_t.

3.2

Revisi kecil dari HAL kemampuan yang diperluas:

• Menghentikan penggunaan get_metadata_vendor_tag_ops. Gunakan get_vendor_tag_ops di camera_common.h.
• Menghentikan penggunaan register_stream_buffers. Semua buffer gralloc yang disediakan oleh framework ke HAL di process_capture_request mungkin baru kapan saja.
• Menambahkan dukungan hasil parsial. process_capture_result mungkin dipanggil beberapa kali dengan subset dari hasil yang tersedia sebelum hasil penelusuran tersedia.
• Tambahkan template manual ke camera3_request_template. Aplikasi dapat menggunakan template ini untuk mengontrol setelan tangkapan secara langsung.
• Mengerjakan ulang spesifikasi streaming dua arah dan input.
• Mengubah jalur yang ditampilkan buffer input. Buffer ditampilkan dalam process_capture_result, bukan process_capture_request.

3.1

Revisi kecil dari HAL kemampuan yang diperluas:

• configure_streams meneruskan flag penggunaan konsumen ke HAL.
• menghapus semua permintaan/buffering yang sedang berlangsung secepat mungkin.

3.0

Revisi pertama HAL kemampuan yang diperluas:

• Perubahan versi utama karena ABI benar-benar berbeda. Tidak ada perubahan pada membutuhkan kemampuan perangkat keras atau model operasional mulai dari versi 2.0.
• Antarmuka permintaan input dan antrean streaming yang dikerjakan ulang: Framework memanggil HAL dengan permintaan berikutnya dan buffer streaming yang sudah dihapus. Dukungan framework sinkronisasi diperlukan untuk implementasi yang efisien.
• Memindahkan pemicu ke permintaan, sebagian besar notifikasi ke hasil.
• Menggabungkan semua callback ke dalam framework menjadi satu struktur, dan semua penyiapan metode menjadi satu panggilan initialize().
• Membuat konfigurasi streaming menjadi satu panggilan untuk menyederhanakan pengelolaan streaming. Aliran dua arah menggantikan STREAM_FROM_STREAM membangun.
• Semantik mode terbatas untuk perangkat hardware lama/terbatas.

2.0

Rilis awal HAL kemampuan yang diperluas (Android 4.2) [camera2.h]:

• Cukup untuk menerapkan android.hardware.Camera yang ada Compute Engine API.
• Mengizinkan antrean ZSL di lapisan layanan kamera.
• Tidak diuji untuk fitur baru apa pun seperti kontrol pengambilan manual, Bayer RAW menangkap, memproses ulang data RAW, dll.

1.0

HAL kamera Android awal (Android 4.0) [camera.h]:

• Dikonversi dari lapisan abstraksi C++ CameraHardwareInterface.
• Mendukung android.hardware.Camera API.

Histori versi modul kamera

Bagian ini berisi informasi pembuatan versi modul untuk hardware Kamera berdasarkan camera_module_t.common.module_api_version. Dua digit heksadesimal paling signifikan mewakili versi utama, dan dua digit terendah signifikan mewakili versi minor.

2.4

Versi modul kamera ini menambahkan perubahan API berikut:

1. Dukungan mode flash. Framework ini dapat mengaktifkan mode flash untuk semua perangkat kamera yang memiliki unit flash, tanpa membuka perangkat kamera. Tujuan perangkat kamera memiliki prioritas yang lebih tinggi untuk mengakses unit flash daripada kamera module; membuka perangkat kamera akan mematikan flash jika telah diaktifkan melalui antarmuka modul. Ketika terjadi konflik sumber daya, seperti open() dipanggil untuk membuka perangkat kamera, modul HAL kamera harus memberi tahu framework melalui callback status mode flash bahwa flash mode telah dinonaktifkan.
2. Dukungan kamera eksternal (misalnya, kamera hot-plug USB). Tujuan Update API menentukan info statis kamera hanya tersedia saat kamera telah terhubung dan siap digunakan untuk kamera hot-plug eksternal. Panggilan untuk mendapatkan suara statis info adalah panggilan tidak valid jika status kamera tidak CAMERA_DEVICE_STATUS_PRESENT. Kerangka kerja ini hanya mengandalkan callback perubahan status perangkat untuk mengelola daftar kamera eksternal yang tersedia.
3. Petunjuk arbitrase kamera. Menambahkan dukungan untuk menunjukkan secara eksplisit jumlah perangkat kamera yang dapat dibuka dan digunakan secara bersamaan. Kepada menentukan kombinasi perangkat yang valid, resource_cost, dan Kolom conflicting_devices harus selalu ditetapkan di bagian Struktur camera_info yang ditampilkan oleh get_camera_info panggilan telepon.
4. Metode inisialisasi modul. Dipanggil oleh layanan kamera setelah modul HAL dimuat untuk memungkinkan inisialisasi HAL satu kali. Metode ini dipanggil sebelum metode modul lainnya dipanggil.

2.3

Versi modul kamera ini menambahkan dukungan perangkat HAL kamera lama yang terbuka. Framework ini dapat menggunakannya untuk membuka perangkat kamera sebagai versi HAL perangkat yang lebih rendah Perangkat HAL jika perangkat yang sama dapat mendukung beberapa versi API perangkat. Panggilan terbuka modul hardware standar (common.methods->open) berlanjut untuk membuka perangkat kamera dengan versi terbaru yang didukung, yaitu juga versi yang tercantum di camera_info_t.device_version.

2,2

Versi modul kamera ini menambahkan dukungan tag vendor dari modul, dan menghentikan vendor_tag_query_ops lama yang sebelumnya hanya dapat diakses dengan perangkat terbuka.

2.1

Versi modul kamera ini menambahkan dukungan untuk callback asinkron ke dari modul HAL kamera, yang digunakan untuk memberi tahu framework tentang perubahan pada status modul kamera. Modul yang menyediakan Metode set_callbacks() harus melaporkan setidaknya nomor versi ini.

2.0

Modul kamera yang melaporkan nomor versi ini menerapkan versi kedua dari antarmuka HAL modul kamera. Perangkat kamera dapat dibuka melalui ini mungkin mendukung perangkat kamera versi 1.0 atau versi 2.0 Antarmuka HAL. Kolom device_version pada camera_info selalu valid; isian static_camera_characteristics pada camera_info valid jika kolom device_version adalah 2.0 atau yang lebih baru.

1.0

Modul kamera yang melaporkan nomor versi ini menerapkan modul kamera HAL. Semua perangkat kamera dapat dibuka melalui ini hanya mendukung versi 1 dari HAL perangkat kamera. Tujuan device_version dan static_camera_characteristics bidang camera_info tidak valid. Hanya android.hardware.Camera API dapat didukung oleh modul ini dan miliknya perangkat.