Dukungan versi kamera

Halaman ini menjelaskan perbedaan versi di HAL Kamera, API, dan pengujian Compatibility Test Suite (CTS) terkait. Ini juga mencakup beberapa perubahan arsitektur yang dibuat 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, yang diekspos melalui class android.hardware.Camera.
Camera API2
Framework kamera tingkat aplikasi di perangkat Android 5.0 dan yang lebih tinggi, yang diekspos melalui paket android.hardware.camera2.
Camera HAL
Lapisan modul kamera yang diimplementasikan oleh vendor SoC. Framework publik level aplikasi dibuat 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 API2 Kamera
Rangkaian tambahan pengujian CTS kamera yang berjalan di atas Camera API2.
Treble
Memisahkan implementasi vendor (software khusus perangkat dan tingkat lebih rendah yang ditulis oleh produsen silicon) dari framework Android OS melalui antarmuka vendor baru.
HIDL
HAL interface definition language diperkenalkan dengan Treble dan digunakan untuk menentukan antarmuka antara HAL dan penggunanya.
VTS
Rangkaian pengujian vendor diperkenalkan bersama Treble.

Camera API

Android menyertakan API kamera berikut.

Camera API1

Android 5.0 tidak lagi menggunakan Camera API1, yang terus dihentikan karena pengembangan platform baru berfokus pada Camera API2. Namun, periode penghentian akan berlangsung lama, dan rilis Android akan terus mendukung aplikasi Camera API1 selama beberapa waktu. Secara khusus, dukungan berlanjut untuk:

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

Camera API2

Framework Camera API2 mengekspos kontrol kamera tingkat rendah ke aplikasi, termasuk alur burst/streaming nol salinan yang efisien dan kontrol eksposur, penguatan, peningkatan white balance, konversi warna, denoise, penajaman, dan banyak lagi. 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 level dukungan berikut:

  • LEGACY: Perangkat ini mengekspos kemampuan ke aplikasi melalui antarmuka Camera API2 yang kemampuannya kira-kira sama dengan yang diekspos 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 frame.
  • LIMITED: Perangkat ini mendukung beberapa kemampuan Camera API2 (tetapi tidak semuanya) 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 streaming output tambahan.
  • EXTERNAL: Perangkat ini mirip dengan perangkat LIMITED dengan beberapa pengecualian; misalnya, beberapa informasi sensor atau lensa mungkin tidak dilaporkan atau memiliki kecepatan frame yang kurang stabil. Tingkat ini digunakan untuk kamera eksternal seperti webcam USB.

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

Level hardware perangkat yang didukung, serta kemampuan Camera API2 tertentu yang didukungnya, tersedia sebagai flag 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 Camera API1, CTS Camera API2, dan pengujian kamera CTS Verifier.

Perangkat yang tidak menampilkan implementasi Camera HAL3.2 dan tidak mampu mendukung antarmuka Camera API2 lengkap tetap harus lulus uji CTS API2 Kamera. Namun, perangkat berjalan dalam mode LEGACY Camera API2 (di mana panggilan Camera API2 dipetakan secara konseptual ke panggilan Camera API1) sehingga setiap 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 diekspos (dan yang menyebabkan kegagalan CTS Camera API2) adalah bug yang sudah ada di HAL Kamera yang ada di perangkat, sehingga akan ditemukan oleh aplikasi Camera API1 yang ada. Kami tidak memperkirakan banyak bug seperti ini (tetapi, bug tersebut harus diperbaiki agar lulus pengujian CTS Camera API2).

Persyaratan VTS

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

Hardening framework kamera

Untuk melakukan hardening keamanan framework media dan kamera, Android 7.0 memindahkan layanan kamera dari server media. Mulai Android 8.0, setiap Camera HAL terbinderisasi berjalan dalam proses yang terpisah dari layanan kamera. Vendor mungkin perlu membuat perubahan pada 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 buffering di antara proses, tidak diperlukan update vendor.

    Stack kamera dan media Android 7.0 di API1 pada HAL3

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

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

    Stack kamera dan media Android 7.0 di API1 pada HAL1

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

Perubahan arsitektur untuk API2

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

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

    Stack media dan kamera Android 7.0 di API2 pada HAL3

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

Persyaratan tambahan

Perubahan arsitektur yang dilakukan untuk meningkatkan keamanan media dan framework 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 berkecepatan tinggi 120/240 FPS. Perangkat juga memerlukan sejumlah kecil RAM tambahan untuk membuat proses baru.
  • Teruskan metadata dalam buffering 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 buffering video di antara 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 pengendali buffer. HAL tidak dapat menggunakan alamat untuk mengidentifikasi buffer karena alamat tersebut dapat menyimpan handle buffer lain setelah HAL menampilkan buffer. Anda harus mengupdate HAL untuk menggunakan handle buffering guna mengidentifikasi buffering. Misalnya, HAL menerima alamat pengendali buffering A, yang menyimpan pengendali buffering A. Setelah HAL menampilkan buffer handle A, alamat buffer handle A dapat menyimpan buffer handle B saat HAL menerimanya lagi.
  • Memperbarui kebijakan SELinux untuk cameraserver. Jika kebijakan SELinux khusus perangkat memberikan izin mediaserver untuk menjalankan kamera, Anda harus memperbarui kebijakan SELinux untuk memberikan izin yang sesuai kepada cameraserver. Sebaiknya jangan mereplikasi kebijakan SELinux mediaserver untuk cameraserver (karena mediaserver dan cameraserver umumnya memerlukan resource yang berbeda di sistem). Server kamera hanya boleh memiliki izin yang diperlukan untuk menjalankan fungsi kamera dan izin terkait kamera yang tidak diperlukan di server media harus dihapus.
  • Pemisahan antara Camera HAL dan cameraserver. Android 8.0 dan yang lebih tinggi juga memisahkan HAL Kamera yang di-binder dalam proses yang berbeda dari cameraserver. IPC melalui antarmuka yang ditentukan HIDL.

Validasi

Untuk semua perangkat yang menyertakan kamera dan menjalankan Android 7.0, verifikasi implementasi dengan menjalankan Android 7.0 CTS. 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 daftar pengujian yang tersedia untuk mengevaluasi Android Camera HAL, lihat Checklist 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 mengkueri kombinasi aliran data.

ICameraDeviceSession

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

Update untuk ICameraDeviceCallback:

  • requestStreamBuffers: Callback sinkron yang dipanggil HAL kamera untuk meminta buffering 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 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 diperbarui di Android 10.

2,5

  • Menambahkan metode notifyDeviceStateChange untuk perangkat guna memberi tahu HAL kamera saat perubahan fisik, seperti melipat, memengaruhi kamera dan pemilihan rute.

2.4

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

Android 9

Rilis Android 9 memperkenalkan update berikut untuk kamera API2 dan antarmuka HAL.

Camera API

  • Memperkenalkan API multi-kamera untuk mendukung perangkat dengan beberapa kamera yang menghadap ke arah yang sama dengan lebih baik, sehingga memungkinkan fitur seperti bokeh dan zoom yang mulus. Hal ini memungkinkan aplikasi melihat beberapa kamera pada perangkat sebagai satu unit logis (kamera logis). Permintaan pengambilan juga dapat dikirim ke setiap perangkat kamera yang dicakup oleh satu kamera logis. Lihat Dukungan Multi-Kamera.
  • Memperkenalkan parameter sesi. Parameter sesi adalah subkumpulan parameter pengambilan yang tersedia, yang dapat menyebabkan penundaan pemrosesan yang parah saat diubah. Biaya ini dapat dimitigasi jika klien meneruskan nilai awal 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 pada perangkat yang didukung. Lihat INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

HAL Kamera

3.4

Update untuk ICameraDeviceSession

Update untuk 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, implementasi Camera HAL vendor harus di-binder. Android 8.0 juga berisi peningkatan utama berikut pada layanan Kamera:

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

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

Platform bersama

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

Lihat dokumentasi developer enableSurfaceSharing untuk mengetahui detail tambahan.

System API untuk mode kamera kustom

API kamera publik menentukan dua mode operasi: perekaman kecepatan 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 pada Configure_streams, kemudian meminta 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 kosong sebanyak mungkin. onCaptureQueueEmpty tidak memerlukan pekerjaan HAL; ini murni merupakan penambahan sisi framework. Aplikasi yang ingin memanfaatkannya harus menambahkan pemroses ke callback tersebut dan merespons dengan tepat. Umumnya, hal ini dilakukan dengan mengirimkan permintaan pengambilan 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 terbaru 3.4 dan 2.4 (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 format RAW apa pun didukung.
  • Alihkan 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 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 HAL dengan kemampuan yang diperluas:

  • Update API pemrosesan ulang OPAQUE dan YUV.
  • Dukungan dasar untuk buffering 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 dari HAL kemampuan yang diperluas:

  • Menghentikan penggunaan get_metadata_vendor_tag_ops. Sebagai gantinya, gunakan get_vendor_tag_ops di camera_common.h.
  • Menghentikan penggunaan register_stream_buffers. Semua buffering gralloc yang disediakan oleh framework ke HAL di process_capture_request dapat menjadi 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.
  • Buat ulang spesifikasi aliran data input dan dua arah.
  • Mengubah jalur return buffer input. Buffer ditampilkan dalam process_capture_result, bukan process_capture_request.

3.1

Revisi kecil HAL dengan 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-nya sama sekali berbeda. Tidak ada perubahan pada kemampuan hardware atau model operasional yang diperlukan dari versi 2.0.
  • Antarmuka permintaan input dan antrean streaming yang dikerjakan ulang: Framework memanggil HAL dengan permintaan berikutnya dan buffering streaming yang telah dihapus dari antrean. Dukungan framework sinkronisasi disertakan, yang diperlukan untuk implementasi yang efisien.
  • Memindahkan pemicu ke dalam permintaan, sebagian besar notifikasi ke dalam hasil.
  • Menggabungkan semua callback ke dalam framework menjadi satu struktur, dan semua metode penyiapan ke dalam satu panggilan initialize().
  • Membuat 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 dengan 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 apa pun 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 pembuatan versi modul untuk modul hardware Kamera, berdasarkan camera_module_t.common.module_api_version. Dua digit heksadesimal yang paling signifikan mewakili versi utama, dan dua yang paling tidak signifikan mewakili versi minor.

2.4

Versi modul kamera ini menambahkan perubahan API berikut:

  1. Dukungan mode flash. Framework ini 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 yang tidak valid jika status kamera bukan CAMERA_DEVICE_STATUS_PRESENT. Framework 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. Untuk menentukan kombinasi perangkat yang valid, kolom resource_cost dan conflicting_devices harus selalu ditetapkan 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 yang 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 buka modul hardware standar (common.methods->open) terus membuka perangkat kamera dengan versi terbaru yang didukung, yang juga merupakan versi yang tercantum di 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 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 menerapkan 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 dari camera_info selalu valid; kolom static_camera_characteristics dari 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 camera_info tidak valid. Hanya android.hardware.Camera API yang dapat didukung oleh modul ini dan perangkatnya.