Dukungan versi kamera

Halaman ini menjelaskan perbedaan versi di HAL, API, dan pengujian Compatibility Test Suite (CTS) terkait Kamera. Dokumen ini juga mencakup beberapa perubahan arsitektur yang dilakukan untuk memperkuat dan mengamankan framework kamera di Android 7.0, peralihan ke Treble di Android 8.0, dan update yang harus dilakukan vendor untuk 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, diekspos melalui class android.hardware.Camera.
Camera API2
Framework kamera tingkat aplikasi di perangkat Android 5.0 dan yang lebih tinggi, diekspos melalui paket android.hardware.camera2.
HAL Kamera
Lapisan modul kamera yang diimplementasikan oleh vendor SoC. Framework publik tingkat aplikasi dibangun di atas HAL kamera.
Camera HAL3.1
Versi HAL perangkat kamera yang dirilis dengan Android 4.4.
Camera HAL3.2
Versi HAL perangkat kamera yang dirilis dengan Android 5.0.
CTS Camera API1
Kumpulan pengujian CTS kamera yang berjalan di atas Camera API1.
CTS Camera API2
Kumpulan pengujian CTS kamera tambahan yang berjalan di atas Camera API2.
Treble
Memisahkan implementasi vendor (software tingkat bawah khusus perangkat yang ditulis oleh produsen silikon) dari framework OS Android melalui antarmuka vendor baru.
HIDL
Bahasa definisi antarmuka HAL diperkenalkan dengan Treble dan digunakan untuk menentukan antarmuka antara HAL dan penggunanya.
VTS
Paket pengujian vendor diperkenalkan bersamaan dengan Treble.

Camera API

Android menyertakan API kamera berikut.

Camera API1

Android 5.0 menghentikan penggunaan Camera API1, yang terus dihentikan secara bertahap karena pengembangan platform baru berfokus pada Camera API2. Namun, periode penghentian akan berlangsung lama, dan rilis Android akan terus mendukung aplikasi Camera API1 untuk beberapa waktu. Secara khusus, dukungan terus diberikan untuk:

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

Camera API2

Framework Camera API2 mengekspos kontrol kamera tingkat rendah ke aplikasi, termasuk alur burst/streaming tanpa salinan yang efisien dan kontrol per frame untuk eksposur, gain, gain white balance, konversi warna, peredam bising, penajaman, dan lainnya. 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. Properti android.info.supportedHardwareLevel yang dapat dikueri aplikasi melalui antarmuka Camera API2 melaporkan salah satu tingkat dukungan berikut:

  • LEGACY: Perangkat ini mengekspos kemampuan ke aplikasi melalui antarmuka Camera API2 yang memiliki kemampuan yang hampir sama dengan yang diekspos ke aplikasi melalui antarmuka Camera API1. Konsep kode framework lama menerjemahkan panggilan Camera API2 menjadi panggilan Camera API1; perangkat lama tidak mendukung fitur Camera API2 seperti kontrol per frame.
  • LIMITED: Perangkat ini mendukung beberapa kemampuan Camera API2 (tetapi tidak semua) dan harus menggunakan Camera HAL 3.2 atau yang lebih tinggi.
  • 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 pengambilan gambar RAW, beserta konfigurasi aliran output tambahan.
  • EXTERNAL: Perangkat ini serupa dengan perangkat LIMITED dengan beberapa pengecualian; misalnya, beberapa informasi sensor atau lensa mungkin tidak dilaporkan atau memiliki kecepatan frame yang kurang stabil. Level ini digunakan untuk kamera eksternal seperti webcam USB.

Kemampuan individual diekspos melalui properti android.request.availableCapabilities di antarmuka Camera API2. Perangkat FULL memerlukan kemampuan MANUAL_SENSOR dan MANUAL_POST_PROCESSING, serta kemampuan lainnya. Kemampuan RAW bersifat opsional, bahkan untuk perangkat FULL. Perangkat LIMITED dapat mengiklankan subset kemampuan ini, termasuk tidak ada satu pun. Namun, kemampuan BACKWARD_COMPATIBLE harus selalu ditentukan.

Level hardware yang didukung perangkat, serta kemampuan Camera API2 spesifik yang didukungnya, tersedia sebagai tanda fitur berikut untuk memungkinkan pemfilteran aplikasi kamera Camera API2 oleh 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

Persyaratan CTS

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

Perangkat yang tidak memiliki implementasi Camera HAL3.2 dan tidak dapat mendukung antarmuka Camera API2 lengkap tetap harus lulus uji CTS Camera API2. Namun, perangkat berjalan dalam mode Camera API2 LEGACY (yang panggilan Camera API2-nya secara konseptual dipetakan ke panggilan Camera API1) sehingga semua pengujian CTS Camera API2 yang terkait dengan fitur atau kemampuan di luar Camera API1 akan otomatis dilewati.

Pada perangkat lama, pengujian CTS Camera API2 yang dijalankan menggunakan antarmuka dan kemampuan Camera API1 publik yang ada tanpa persyaratan baru. Bug yang terekspos (dan menyebabkan kegagalan CTS Camera API2) adalah bug yang sudah ada di HAL Kamera perangkat, sehingga akan ditemukan oleh aplikasi Camera API1 yang ada. Kami tidak mengharapkan banyak bug seperti ini (namun, bug semacam itu harus diperbaiki agar lulus uji CTS Camera API2).

Persyaratan VTS

Perangkat yang menjalankan Android 8.0 dan yang lebih tinggi dengan implementasi HAL yang terikat harus lulus pengujian VTS Camera.

Penguatan framework kamera

Untuk memperkuat keamanan framework media dan kamera, Android 7.0 memindahkan layanan kamera keluar dari mediaserver. Mulai Android 8.0, setiap HAL Kamera yang terikat berjalan dalam proses yang terpisah dari layanan kamera. Vendor mungkin perlu melakukan perubahan di HAL kamera, bergantung pada versi API dan HAL yang digunakan. Bagian berikut menjelaskan perubahan arsitektur di AP1 dan AP2 untuk HAL1 dan HAL3, serta persyaratan umum.

Perubahan arsitektur untuk API1

Perekaman video API1 dapat mengasumsikan bahwa kamera dan encoder video berada dalam proses yang sama. Saat menggunakan API1 di:

  • HAL3, tempat layanan kamera menggunakan BufferQueue untuk meneruskan buffer antar-proses, tidak memerlukan update vendor.

    Stack media dan kamera Android 7.0 di API1 pada HAL3

    Gambar 1. Stack media dan kamera Android 7.0 di API1 pada HAL3

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

    Stack media dan kamera Android 7.0 di API1 pada HAL1

    Gambar 2. Stack media dan kamera Android 7.0 di API1 pada HAL1

Perubahan arsitektur untuk API2

Untuk API2 di HAL1 atau HAL3, BufferQueue meneruskan buffer sehingga jalur tersebut terus berfungsi. Arsitektur Android 7.0 untuk API2 di:

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

    Kamera dan stack media Android 7.0 di API2 pada HAL3

    Gambar 3. Stack media dan kamera Android 7.0 di API2 pada HAL3

Persyaratan tambahan

Perubahan arsitektur yang dilakukan untuk memperkuat keamanan framework media dan kamera mencakup persyaratan perangkat tambahan berikut.

  • Umum. Perangkat memerlukan bandwidth tambahan karena IPC, yang dapat memengaruhi kasus penggunaan kamera yang sensitif terhadap waktu seperti perekaman video berkecepatan tinggi. Vendor dapat mengukur dampak sebenarnya dengan menjalankan android.hardware.camera2.cts.PerformanceTest dan aplikasi Google Kamera untuk perekaman video kecepatan tinggi 120/240 FPS. Perangkat juga memerlukan RAM tambahan dalam jumlah kecil untuk membuat proses baru.
  • Teruskan metadata di buffer video (khusus HAL1). Jika HAL1 menyimpan metadata, bukan data frame YUV sebenarnya dalam buffer video, HAL harus menggunakan kMetadataBufferTypeNativeHandleSource sebagai jenis buffer metadata dan meneruskan VideoNativeHandleMetadata dalam buffer video. (kMetadataBufferTypeCameraSource tidak lagi didukung di Android 7.0.) Dengan VideoNativeHandleMetadata, framework kamera dan media dapat meneruskan buffer video antar-proses dengan melakukan serialisasi dan deserialisasi handle native dengan benar.
  • Alamat handle buffer tidak selalu menyimpan buffer yang sama (khusus HAL3). Untuk setiap permintaan pengambilan, HAL3 mendapatkan alamat buffer handle. HAL tidak dapat menggunakan alamat untuk mengidentifikasi buffer karena alamat dapat menyimpan handle buffer lain setelah HAL menampilkan buffer. Anda harus mengupdate HAL untuk menggunakan handle buffer guna mengidentifikasi buffer. Misalnya, HAL menerima alamat handle buffer A, yang menyimpan handle buffer A. Setelah HAL menampilkan handle buffer A, alamat handle buffer A dapat menyimpan handle buffer B pada saat HAL menerimanya lain kali.
  • Perbarui kebijakan SELinux untuk cameraserver. Jika kebijakan SELinux khusus perangkat memberikan izin mediaserver untuk menjalankan kamera, Anda harus memperbarui kebijakan SELinux untuk memberikan izin yang tepat kepada cameraserver. Kami tidak menganjurkan mereplikasi kebijakan SELinux mediaserver untuk cameraserver (karena mediaserver dan cameraserver umumnya memerlukan resource yang berbeda dalam sistem). Cameraserver hanya boleh memiliki izin yang diperlukan untuk menjalankan fungsi kamera dan izin terkait kamera yang tidak diperlukan di mediaserver harus dihapus.
  • Pemisahan antara Camera HAL dan server kamera. Android 8.0 dan yang lebih tinggi juga memisahkan binderized Camera HAL dalam proses yang berbeda dari cameraserver. IPC dilakukan melalui antarmuka yang ditentukan HIDL.

Validasi

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

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

Histori versi HAL Kamera

Untuk melihat daftar pengujian yang tersedia untuk mengevaluasi Android Camera HAL, lihat Daftar Periksa Pengujian HAL Kamera.

Android 10

Android 10 memperkenalkan update berikut.

Camera API

HAL Kamera

Versi Camera HAL berikut diperbarui di Android 10.

3.5

ICameraDevice

  • getPhysicalCameraCharacteristics: Informasi kamera statis untuk ID kamera fisik yang mendukung perangkat kamera logis. Lihat Dukungan Multi-Kamera.
  • isStreamCombinationSupported: Metode ini mendukung API publik yang membantu klien membuat kueri apakah konfigurasi sesi didukung. Lihat API untuk membuat kueri kombinasi streaming.

ICameraDeviceSession

  • isReconfigurationNeeded: Metode yang memberi tahu framework kamera apakah konfigurasi ulang streaming lengkap diperlukan untuk kemungkinan nilai parameter sesi baru. Hal ini membantu menghindari penundaan konfigurasi ulang kamera yang tidak perlu. Lihat Kueri konfigurasi ulang sesi.
  • API pengelolaan buffer HAL: API ini memungkinkan HAL kamera meminta buffer dari framework kamera hanya jika diperlukan, bukan menggabungkan setiap permintaan pengambilan dengan buffer terkaitnya di seluruh pipeline kamera, sehingga berpotensi menghemat memori secara signifikan.
    • signalStreamFlush: Memberi sinyal ke HAL bahwa layanan kamera akan melakukan configureStreams_3_5 dan HAL harus menampilkan semua buffer dari aliran yang ditentukan.
    • configureStreams_3_5: Mirip dengan ICameraDevice3.4.configureStreams, tetapi selain itu, penghitung streamConfigCounter disediakan untuk memeriksa kondisi persaingan antara panggilan configureStreams_3_5 dan signalStreamFlush.

Update untuk ICameraDeviceCallback:

  • requestStreamBuffers: Callback sinkron yang dipanggil HAL kamera untuk meminta buffer ke server kamera. Lihat requestStreamBuffers.
  • returnStreamBuffers: Callback sinkron untuk HAL kamera guna menampilkan buffer output ke server 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
  • Kemampuan
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
  • Nilai untuk kunci ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • Konfigurasi aliran 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 agar perangkat dapat memberi tahu HAL kamera saat perubahan fisik, seperti melipat, memengaruhi kamera dan perutean.

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 dan antarmuka HAL kamera.

Camera API

  • Memperkenalkan multi-camera API untuk mendukung perangkat dengan beberapa kamera yang menghadap ke arah yang sama dengan lebih baik, sehingga memungkinkan fitur seperti bokeh dan zoom yang lancar. Hal ini memungkinkan aplikasi melihat beberapa kamera di perangkat sebagai satu unit logis (kamera logis). Permintaan pengambilan gambar juga dapat dikirim ke setiap perangkat kamera yang tercakup dalam satu kamera logis. Lihat Dukungan Multi-Kamera.
  • Memperkenalkan parameter sesi. Parameter sesi adalah subset dari parameter pengambilan yang tersedia yang dapat menyebabkan penundaan pemrosesan yang parah jika diubah. Biaya ini dapat dikurangi jika klien meneruskan nilai awalnya selama inisialisasi sesi pengambilan. Lihat Parameter Sesi.
  • Menambahkan kunci data stabilisasi optik (OIS) untuk stabilisasi dan efek tingkat aplikasi. 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 gantinya.
  • Menambahkan mode koreksi distorsi di CaptureRequest. Lihat DISTORTION_CORRECTION_MODE.
  • Menambahkan dukungan untuk kamera USB/UVC eksternal di perangkat yang didukung. Lihat INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

HAL Kamera

3.4

Perubahan pada ICameraDeviceSession

Perubahan pada ICameraDeviceCallback

3.3

Kunci berikut ditambahkan ke metadata kamera di Android 9.

  • Kemampuan
    • 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, penerapan HAL Kamera vendor harus binderized. Android 8.0 juga berisi peningkatan utama berikut pada layanan Kamera:

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

Lihat bagian di bawah untuk mengetahui informasi selengkapnya tentang fitur ini.

Permukaan bersama

Fitur ini memungkinkan hanya satu set buffer untuk mendorong dua output, seperti pratinjau dan encoding video, yang menurunkan konsumsi daya dan memori. Untuk mendukung fitur ini, produsen perangkat harus memastikan bahwa implementasi HAL kamera dan HAL gralloc mereka dapat membuat buffer gralloc yang digunakan oleh beberapa konsumen yang berbeda (seperti composer/GPU hardware dan encoder video), bukan hanya satu konsumen. Layanan kamera meneruskan flag penggunaan konsumen ke HAL kamera dan HAL gralloc; keduanya perlu mengalokasikan jenis buffer yang tepat, atau HAL kamera perlu menampilkan error bahwa kombinasi konsumen ini tidak didukung.

Lihat enableSurfaceSharing dokumentasi developer untuk mengetahui detail tambahan.

System API untuk mode kamera kustom

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

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

Untuk mendukung fitur ini, OEM hanya perlu menambahkan mode baru ke HAL mereka, yang dipicu oleh bilangan bulat ini yang diteruskan ke HAL di configure_streams, lalu membuat 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 dengan memastikan antrean permintaan sekosong mungkin. onCaptureQueueEmpty tidak memerlukan pekerjaan HAL; ini murni penambahan sisi framework. Aplikasi yang ingin memanfaatkannya perlu menambahkan pemroses ke callback tersebut dan merespons dengan tepat. Biasanya, hal itu dilakukan dengan mengirim permintaan pengambilan gambar lain ke perangkat kamera.

Antarmuka HIDL kamera

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

3.4

Penambahan kecil 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 metadata statis ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE sebagai wajib jika ada format RAW yang didukung.
  • Mengalihkan kolom camera3_stream_t data_space ke definisi yang lebih fleksibel, menggunakan definisi encoding ruang data versi 0.
  • Penambahan metadata umum yang tersedia untuk digunakan pada 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 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 kolom rotasi ke camera3_stream_t.
  • Penambahan mode operasi konfigurasi streaming camera3 ke camera3_stream_configuration_t.

3.2

Revisi kecil HAL kemampuan yang diperluas:

  • Tidak digunakan lagi get_metadata_vendor_tag_ops. Sebagai gantinya, gunakan get_vendor_tag_ops di camera_common.h.
  • Tidak digunakan lagi register_stream_buffers. Semua buffer gralloc yang disediakan oleh framework ke HAL di process_capture_request dapat berupa buffer baru kapan saja.
  • Menambahkan dukungan hasil parsial. process_capture_result dapat dipanggil beberapa kali dengan subset hasil yang tersedia sebelum hasil lengkap tersedia.
  • Tambahkan template manual ke camera3_request_template. Aplikasi dapat menggunakan template ini untuk mengontrol setelan pengambilan secara langsung.
  • Mengerjakan ulang spesifikasi aliran input dan dua arah.
  • Ubah jalur kembali buffer input. Buffer ditampilkan di process_capture_result, bukan process_capture_request.

3.1

Revisi kecil HAL kemampuan yang diperluas:

  • configure_streams meneruskan tanda penggunaan konsumen ke HAL.
  • Panggilan flush untuk membatalkan semua permintaan/buffer dalam proses secepat mungkin.

3.0

Revisi pertama HAL dengan kemampuan yang diperluas:

  • Perubahan versi utama karena ABI benar-benar berbeda. Tidak ada perubahan pada kemampuan hardware yang diperlukan atau model operasional dari 2.0.
  • Antarmuka permintaan input dan antrean streaming yang dikerjakan ulang: Framework memanggil HAL dengan permintaan berikutnya dan buffer streaming yang sudah dikeluarkan dari antrean. Dukungan framework sinkronisasi disertakan, yang diperlukan untuk penerapan yang efisien.
  • Memindahkan pemicu ke dalam permintaan, sebagian besar notifikasi ke dalam hasil.
  • Menggabungkan semua callback ke framework menjadi satu struktur, dan semua metode penyiapan menjadi satu panggilan initialize().
  • Mengubah konfigurasi streaming menjadi satu panggilan untuk menyederhanakan pengelolaan streaming. Aliran dua arah menggantikan konstruksi STREAM_FROM_STREAM.
  • 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 API yang ada.
  • Memungkinkan antrean ZSL di lapisan layanan kamera.
  • Tidak diuji untuk fitur baru seperti kontrol pengambilan manual, pengambilan Bayer RAW, pemrosesan ulang data RAW, dll.

1.0

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

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

Histori versi modul kamera

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

2.4

Versi modul kamera ini menambahkan perubahan API berikut:

  1. Dukungan mode senter. Framework dapat mengaktifkan mode senter untuk perangkat kamera apa pun yang memiliki unit flash, tanpa membuka perangkat kamera. Perangkat kamera memiliki prioritas yang lebih tinggi untuk mengakses unit flash daripada modul kamera; membuka perangkat kamera akan menonaktifkan senter jika telah diaktifkan melalui antarmuka modul. Jika ada konflik resource, seperti open() dipanggil untuk membuka perangkat kamera, modul HAL kamera harus memberi tahu framework melalui callback status mode senter bahwa mode senter telah dinonaktifkan.
  2. Dukungan kamera eksternal (misalnya, kamera hot-plug USB). Update API menentukan bahwa info statis kamera hanya tersedia saat kamera terhubung dan siap digunakan untuk kamera hot-plug eksternal. Panggilan untuk mendapatkan info statis adalah panggilan tidak valid saat status kamera bukan CAMERA_DEVICE_STATUS_PRESENT. Framework 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. Untuk menentukan kombinasi perangkat yang valid, kolom resource_cost dan conflicting_devices harus selalu disetel dalam struktur camera_info yang ditampilkan oleh panggilan get_camera_info.
  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 terbuka. Framework dapat menggunakannya untuk membuka perangkat kamera sebagai perangkat HAL versi HAL perangkat yang lebih rendah jika perangkat yang sama dapat mendukung beberapa versi API perangkat. Panggilan terbuka modul hardware standar (common.methods->open) terus membuka perangkat kamera dengan versi terbaru yang didukung, yang juga merupakan versi yang tercantum dalam camera_info_t.device_version.

2.2

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

2.1

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

2.0

Modul kamera yang melaporkan nomor versi ini mengimplementasikan versi kedua antarmuka HAL modul kamera. Perangkat kamera yang dapat dibuka melalui modul ini dapat mendukung antarmuka HAL perangkat kamera versi 1.0 atau versi 2.0. Kolom device_version camera_info selalu valid; kolom static_camera_characteristics camera_info valid jika kolom device_version adalah 2.0 atau yang lebih tinggi.

1.0

Modul kamera yang melaporkan nomor versi ini mengimplementasikan antarmuka HAL modul kamera awal. Semua perangkat kamera yang dapat dibuka melalui modul ini hanya mendukung HAL perangkat kamera versi 1. Kolom device_version dan static_camera_characteristics dari camera_info tidak valid. Hanya API android.hardware.Camera yang dapat didukung oleh modul ini dan perangkatnya.