หน้านี้แสดงรายละเอียดของเวอร์ชันที่แตกต่างกันใน HAL ของกล้อง, API และการทดสอบชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) ที่เกี่ยวข้อง นอกจากนี้ ยังครอบคลุมถึงการเปลี่ยนแปลงเชิงโครงสร้างหลายประการที่ทําขึ้นเพื่อเพิ่มความแข็งแกร่งและรักษาความปลอดภัยให้กับเฟรมเวิร์กกล้องใน Android 7.0, การเปลี่ยนไปใช้ Treble ใน Android 8.0 และการอัปเดตที่ผู้ให้บริการต้องทําเพื่อรองรับการเปลี่ยนแปลงเหล่านี้ในการใช้งานกล้อง
คำศัพท์
หน้านี้ใช้คําศัพท์ต่อไปนี้
- API กล้องถ่ายรูป1
- เฟรมเวิร์กกล้องระดับแอปในอุปกรณ์ Android 4.4 และต่ำกว่าที่แสดงผ่านคลาส
android.hardware.Camera
- Camera API2
- เฟรมเวิร์กกล้องระดับแอปบนอุปกรณ์ Android 5.0 ขึ้นไป ซึ่งจะแสดงผ่านแพ็กเกจ
android.hardware.camera2
- HAL ของกล้อง
- เลเยอร์โมดูลกล้องที่ผู้ให้บริการ SoC นำมาใช้งาน เฟรมเวิร์กสาธารณะระดับแอปสร้างขึ้นจาก HAL ของกล้อง
- Camera HAL3.1
- เวอร์ชัน HAL ของอุปกรณ์กล้องที่เปิดตัวพร้อม Android 4.4
- Camera HAL3.2
- เวอร์ชัน HAL ของอุปกรณ์กล้องที่เปิดตัวใน Android 5.0
- API1 CTS ของกล้อง
- ชุดการทดสอบ CTS ของกล้องที่ทำงานด้านบนของ API1 ของกล้อง
- Camera API2 CTS
- ชุดการทดสอบ CTS ของกล้องเพิ่มเติมที่ทำงานบน Camera API2
- เสียงแหลม
- แยกการติดตั้งใช้งานของผู้ให้บริการ (ซอฟต์แวร์ระดับล่างเฉพาะอุปกรณ์ที่เขียนโดยผู้ผลิตชิป) ออกจากเฟรมเวิร์กระบบปฏิบัติการ Android ผ่านอินเทอร์เฟซผู้ให้บริการแบบใหม่
- HIDL
- ภาษาคำจำกัดความอินเทอร์เฟซ HAL ที่เปิดตัวพร้อมกับ Treble และใช้เพื่อระบุอินเทอร์เฟซระหว่าง HAL กับผู้ใช้
- VTS
- เปิดตัวชุดทดสอบสำหรับผู้ให้บริการควบคู่กับ Treble
API กล้อง
Android มี API กล้องต่อไปนี้
API กล้องถ่ายรูป1
Android 5.0 เลิกใช้งาน Camera API1 แล้ว และเราจะเลิกใช้งานต่อไปเนื่องจากการพัฒนาแพลตฟอร์มใหม่มุ่งเน้นที่ Camera API2 อย่างไรก็ตาม ระยะเลิกใช้งานจะยาวนานและ Android รุ่นต่างๆ จะยังคงรองรับแอป Camera API1 เป็นระยะเวลาหนึ่ง กล่าวอย่างเจาะจงคือ เรามีการสนับสนุนสำหรับบริการต่อไปนี้
- อินเทอร์เฟซกล้องถ่ายรูป API1 สำหรับแอป แอปกล้องที่สร้างจาก Camera API1 ควรทำงานได้เช่นเดียวกับในอุปกรณ์ที่ใช้ Android เวอร์ชันที่ต่ำกว่า
- เวอร์ชัน HAL ของกล้อง รวมถึงรองรับ Camera HAL1.0
Camera API2
เฟรมเวิร์ก Camera API2 ช่วยให้แอปควบคุมกล้องในระดับล่างได้ ซึ่งรวมถึงโฟลว์การถ่ายภาพ/การสตรีมแบบ Zero Copy ที่มีประสิทธิภาพ และการควบคุมการรับแสง อัตราขยาย การเพิ่มไวท์บาลานซ์ การแปลงสี การตัดเสียงรบกวน การทำให้คมชัด และอีกมากมาย ดูรายละเอียดได้ที่ ภาพรวมวิดีโอ Google I/O
Android 5.0 ขึ้นไปจะมี Camera API2 รวมอยู่ด้วย แต่อุปกรณ์ที่ใช้ Android 5.0 ขึ้นไปอาจไม่รองรับฟีเจอร์ Camera API2 ทั้งหมด พร็อพเพอร์ตี้ android.info.supportedHardwareLevel
ที่แอปสามารถค้นหาผ่านอินเทอร์เฟซ Camera API2 จะรายงานระดับการรองรับอย่างใดอย่างหนึ่งต่อไปนี้
LEGACY
: อุปกรณ์เหล่านี้เปิดตัวความสามารถของแอปผ่านอินเทอร์เฟซ Camera API2 ที่มีความสามารถโดยประมาณเหมือนกับแอปผ่านอินเทอร์เฟซ Camera API1 โค้ดเฟรมเวิร์กเดิมจะแปลการเรียก Camera API2 เป็น Camera API1 ในทางแนวคิด อุปกรณ์เดิมไม่รองรับฟีเจอร์ของ Camera API2 เช่น การควบคุมต่อเฟรมLIMITED
: อุปกรณ์เหล่านี้รองรับความสามารถบางอย่างของ Camera API2 (แต่ไม่ใช่ทั้งหมด) และต้องใช้ Camera HAL 3.2 ขึ้นไปFULL
: อุปกรณ์เหล่านี้รองรับความสามารถหลักทั้งหมดของ Camera API2 และต้องใช้ Camera HAL 3.2 ขึ้นไป และ Android 5.0 ขึ้นไปLEVEL_3
: อุปกรณ์เหล่านี้รองรับการประมวลผล YUV อีกครั้งและการจับภาพภาพ RAW รวมถึงการกำหนดค่าสตรีมเอาต์พุตเพิ่มเติมEXTERNAL
: อุปกรณ์เหล่านี้คล้ายกับอุปกรณ์LIMITED
โดยมีข้อยกเว้นบางประการ เช่น ระบบอาจไม่รายงานข้อมูลเซ็นเซอร์หรือเลนส์บางรายการ หรืออัตราเฟรมอาจไม่เสถียร ระดับนี้ใช้กับกล้องภายนอก เช่น เว็บแคม USB
ความสามารถแต่ละอย่างจะแสดงผ่านพร็อพเพอร์ตี้ android.request.availableCapabilities
ในอินเทอร์เฟซ Camera API2 อุปกรณ์ FULL
ต้องมีความสามารถ MANUAL_SENSOR
และ MANUAL_POST_PROCESSING
รวมไปถึงความสามารถอื่นๆ ความสามารถ RAW
เป็นความสามารถที่ไม่บังคับสำหรับอุปกรณ์ FULL
อุปกรณ์ LIMITED
สามารถโฆษณาความสามารถย่อยๆ เหล่านี้ได้ ไม่ว่าจะมีหรือไม่มีความสามารถดังกล่าว อย่างไรก็ตาม คุณต้องกำหนดความสามารถ BACKWARD_COMPATIBLE
เสมอ
ระดับฮาร์ดแวร์ที่รองรับของอุปกรณ์ รวมถึงความสามารถเฉพาะของ Camera API2 ที่รองรับจะแสดงเป็น Flag ฟีเจอร์ต่อไปนี้เพื่ออนุญาตให้ Google Play กรองแอปกล้อง 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
ข้อกำหนด CTS
อุปกรณ์ที่ใช้ Android 5.0 ขึ้นไปต้องผ่านการทดสอบ Camera API1 CTS, Camera API2 CTS และการทดสอบกล้องของ CTS Verifier
อุปกรณ์ที่ไม่ได้ใช้ Camera HAL3.2 และไม่สามารถรองรับอินเทอร์เฟซ Camera API2 เต็มรูปแบบยังคงต้องผ่านการทดสอบ CTS ของ Camera API2 อย่างไรก็ตาม อุปกรณ์ทำงานในโหมด Camera API2LEGACY
(ซึ่งการเรียกใช้ Camera API2 จะแมปกับแนวคิดการเรียกใช้ Camera API1) ระบบจะข้ามการทดสอบ CTS ของ Camera API2 ที่เกี่ยวข้องกับฟีเจอร์หรือความสามารถที่นอกเหนือจาก Camera API1 โดยอัตโนมัติ
ในอุปกรณ์รุ่นเดิม การทดสอบ CTS ของ Camera API2 ที่ทำงานจะใช้อินเทอร์เฟซและความสามารถของ Camera API1 สาธารณะที่มีอยู่โดยไม่มีข้อกำหนดใหม่ ข้อบกพร่องที่แสดง (และทําให้ Camera API2 ไม่ผ่าน CTS) คือข้อบกพร่องที่มีอยู่ใน HAL ของกล้องที่มีอยู่ของอุปกรณ์อยู่แล้ว ดังนั้นแอป Camera API1 ที่มีอยู่จะพบข้อบกพร่องดังกล่าว เราไม่คาดว่าจะมีข้อบกพร่องลักษณะนี้มากนัก (แต่ต้องมีการแก้ไขข้อบกพร่องดังกล่าวให้ผ่านการทดสอบ Camera API2 CTS)
ข้อกำหนด VTS
อุปกรณ์ที่ใช้ Android 8.0 ขึ้นไปซึ่งมีการใช้ HAL แบบ Binderized ต้องผ่านการทดสอบ VTS ของกล้อง
การปิดขอบกรอบกล้อง
Android 7.0 ย้ายบริการกล้องออกจาก Mediaserver เพื่อทำให้ความปลอดภัยของเฟรมเวิร์กสื่อและกล้องแข็งแกร่งขึ้น ตั้งแต่ Android 8.0 เป็นต้นไป HAL ของกล้องแต่ละตัวจะทำงานในกระบวนการที่แยกจากบริการกล้อง ผู้ให้บริการอาจต้องทําการเปลี่ยนแปลงใน HAL ของกล้อง ทั้งนี้ขึ้นอยู่กับเวอร์ชัน API และ HAL ที่ใช้ ส่วนต่อไปนี้จะอธิบายการเปลี่ยนแปลงสถาปัตยกรรมใน AP1 และ AP2 สำหรับ HAL1 และ HAL3 รวมถึงข้อกำหนดทั่วไป
การเปลี่ยนแปลงสถาปัตยกรรมสำหรับ API1
การบันทึกวิดีโอ API1 อาจถือว่ากล้องและโปรแกรมเปลี่ยนไฟล์วิดีโออยู่ในกระบวนการเดียวกัน เมื่อใช้ API1 ใน
- HAL3 ซึ่งบริการกล้องใช้ BufferQueue เพื่อส่งบัฟเฟอร์ระหว่างกระบวนการ ไม่จำเป็นต้องอัปเดตผู้ให้บริการ
- HAL1 ซึ่งรองรับการส่งข้อมูลเมตาในบัฟเฟอร์วิดีโอ ผู้ให้บริการต้องอัปเดต HAL เพื่อใช้
kMetadataBufferTypeNativeHandleSource
(Android 7.0 ไม่รองรับkMetadataBufferTypeCameraSource
อีกต่อไป)
การเปลี่ยนแปลงสถาปัตยกรรมสําหรับ API2
สำหรับ API2 ใน HAL1 หรือ HAL3 BufferQueue จะส่งบัฟเฟอร์เพื่อให้เส้นทางเหล่านั้นทำงานต่อไป สถาปัตยกรรม Android 7.0 สำหรับ API2 ในอุปกรณ์ต่อไปนี้
- HAL1 ไม่ได้รับผลกระทบจากการย้ายข้อมูล cameraservice และไม่จำเป็นต้องอัปเดตผู้ให้บริการ
- HAL3 ได้รับผลกระทบ แต่ไม่จําเป็นต้องอัปเดตผู้ให้บริการ
ข้อกำหนดเพิ่มเติม
การเปลี่ยนแปลงเชิงสถาปัตยกรรมที่ออกแบบมาเพื่อเสริมความปลอดภัยของสื่อและเฟรมเวิร์กกล้องรวมถึงข้อกำหนดเพิ่มเติมของอุปกรณ์ดังต่อไปนี้
- ทั่วไป อุปกรณ์ต้องใช้แบนด์วิดท์เพิ่มเติมเนื่องจาก IPC ซึ่งอาจส่งผลต่อกรณีการใช้งานกล้องที่คำนึงถึงเวลา เช่น การบันทึกวิดีโอความเร็วสูง ผู้ให้บริการสามารถวัดผลลัพธ์จริงได้โดยเรียกใช้
android.hardware.camera2.cts.PerformanceTest
และแอป Google Camera เพื่อบันทึกวิดีโอความเร็วสูง 120/240 FPS นอกจากนี้ อุปกรณ์ยังต้องใช้ RAM เพิ่มเติมอีกเล็กน้อยเพื่อสร้างกระบวนการใหม่ - ส่งข้อมูลเมตาในบัฟเฟอร์วิดีโอ (HAL1 เท่านั้น) หาก HAL1 จัดเก็บข้อมูลเมตาแทนข้อมูลเฟรม YUV จริงในบัฟเฟอร์วิดีโอ HAL ต้องใช้
kMetadataBufferTypeNativeHandleSource
เป็นประเภทบัฟเฟอร์ข้อมูลเมตาและส่งVideoNativeHandleMetadata
ในบัฟเฟอร์วิดีโอ (kMetadataBufferTypeCameraSource
ไม่รองรับใน Android 7.0 อีกต่อไป) เมื่อใช้VideoNativeHandleMetadata
เฟรมเวิร์กกล้องและสื่อจะส่งบัฟเฟอร์วิดีโอระหว่างกระบวนการได้โดยการจัดรูปแบบและถอดรูปแบบแฮนเดิลเนทีฟอย่างถูกต้อง - ที่อยู่แฮนเดิลของบัฟเฟอร์ไม่เก็บบัฟเฟอร์เดียวกันเสมอไป (เฉพาะ HAL3 เท่านั้น) สําหรับคําขอบันทึกแต่ละรายการ HAL3 จะได้รับที่อยู่ของตัวแฮนเดิลบัฟเฟอร์ HAL ไม่สามารถใช้ที่อยู่เพื่อระบุบัฟเฟอร์ เนื่องจากที่อยู่อาจจัดเก็บแฮนเดิลอื่นของบัฟเฟอร์หลังจากที่ HAL ส่งคืนบัฟเฟอร์ คุณต้องอัปเดต HAL เพื่อใช้ตัวแฮนเดิลบัฟเฟอร์เพื่อระบุบัฟเฟอร์ เช่น HAL ได้รับที่อยู่แฮนเดิลบัฟเฟอร์ A ซึ่งจัดเก็บแฮนเดิลบัฟเฟอร์ A หลังจาก HAL แสดงผลแฮนเดิล A ของบัฟเฟอร์ A ที่อยู่ A ของบัฟเฟอร์ A อาจเก็บบัฟเฟอร์ B ในครั้งถัดไปที่ HAL ได้รับ
- อัปเดตนโยบาย SELinux สำหรับ cameraserver หากนโยบาย SELinux สำหรับอุปกรณ์เฉพาะให้สิทธิ์ mediaserver ในการใช้งานกล้อง คุณจะต้องอัปเดตนโยบาย SELinux เพื่อให้สิทธิ์ที่เหมาะสมแก่ cameraserver เราขอแนะนำไม่ให้ทำซ้ำนโยบาย SELinux ของ mediaserver สำหรับ cameraserver (เนื่องจากโดยทั่วไปแล้ว mediaserver และ cameraserver ต้องใช้ทรัพยากรที่แตกต่างกันในระบบ) Cameraserver ควรมีเฉพาะสิทธิ์ที่จําเป็นต่อฟังก์ชันการทํางานของกล้อง และควรนําสิทธิ์ที่ไม่จําเป็นซึ่งเกี่ยวข้องกับกล้องใน Mediaserver ออก
- การแยกระหว่าง HAL ของกล้องกับเซิร์ฟเวอร์กล้อง Android 8.0 ขึ้นไปจะแยก HAL ของกล้องที่ถูกผูกมัดด้วยกระบวนการที่ต่างจาก Cameraserver IPC จะดำเนินการผ่านอินเทอร์เฟซที่HIDL กำหนด
การตรวจสอบความถูกต้อง
สำหรับอุปกรณ์ทั้งหมดที่มีกล้องและใช้ Android 7.0 ให้ยืนยันการใช้งานโดยเรียกใช้ Android 7.0 CTS แม้ว่า Android 7.0 จะไม่มีการทดสอบ CTS ใหม่ที่ยืนยันการเปลี่ยนแปลงบริการกล้อง แต่การทดสอบ CTS ที่มีอยู่จะไม่สำเร็จหากไม่ได้อัปเดตตามที่ระบุไว้ด้านบน
สำหรับอุปกรณ์ทั้งหมดที่มีกล้องและใช้งาน Android 8.0 ขึ้นไป ให้ยืนยันการใช้งานของผู้ให้บริการโดยเรียกใช้ VTS
ประวัติเวอร์ชัน HAL ของกล้อง
ดูรายการการทดสอบที่ใช้ประเมิน HAL ของกล้อง Android ได้ที่รายการตรวจสอบการทดสอบ HAL ของกล้อง
Android 10
Android 10 ขอแนะนำการอัปเดตต่อไปนี้
API กล้องถ่ายรูป
- การปรับปรุงกล้องหลายตัวที่ช่วยให้ใช้กล้องจริงได้ทีละตัวหรือผ่านกล้องเสมือนที่เกี่ยวข้องโดยซ่อนรหัสกล้องจริง โปรดดู การรองรับกล้องหลายตัว
- ความสามารถในการตรวจสอบว่าระบบรองรับการกำหนดค่าเซสชันหนึ่งๆ หรือไม่โดยไม่เพิ่มภาระงานด้านประสิทธิภาพในการสร้างเซสชันใหม่
ดู
CameraDevice
- ความสามารถในการดึงข้อมูลการกำหนดค่าสตรีมที่แนะนำสำหรับกรณีการใช้งานหนึ่งๆ เพื่อให้ไคลเอ็นต์มีประสิทธิภาพและประหยัดพลังงานมากขึ้น ดู
getRecommendedStreamConfigurationMap
- การรองรับ รูปแบบรูปภาพ JPEG ที่มีความลึก ดูรายละเอียดเพิ่มเติมได้ใน ข้อกำหนดเกี่ยวกับภาพระดับไดนามิก
- การรองรับ รูปแบบรูปภาพ HEIC ดูการถ่ายภาพ HEIF
- การปรับปรุงความเป็นส่วนตัว คีย์บางอย่างจําเป็นต่อไคลเอ็นต์เพื่อให้มีสิทธิ์
CameraCharacteristics
ก่อนจึงจะดึงข้อมูลจากCameraCharacteristics
ได้CAMERA
โปรดดูgetKeysNeedingPermission
HAL ของกล้อง
HAL ของกล้องเวอร์ชันต่อไปนี้ได้รับการอัปเดตใน Android 10
3.5
ICameraDevice
-
getPhysicalCameraCharacteristics
: ข้อมูลกล้องแบบคงที่สำหรับรหัสกล้องจริงที่สำรองข้อมูลอุปกรณ์กล้องแบบลอจิคัล ดูหัวข้อ การรองรับกล้องหลายตัว isStreamCombinationSupported
: วิธีการนี้รองรับ API สาธารณะที่ช่วยให้ไคลเอ็นต์สามารถสอบถามได้ว่าระบบรองรับการกำหนดค่าเซสชันหรือไม่ ดูAPI เพื่อค้นหาชุดค่าผสมสตรีม
ICameraDeviceSession
-
isReconfigurationNeeded
: วิธีการที่บอกเฟรมเวิร์กกล้องว่าจำเป็นต้องกำหนดค่าสตรีมใหม่ทั้งหมดสำหรับค่าพารามิเตอร์เซสชันใหม่หรือไม่ วิธีนี้จะช่วยหลีกเลี่ยงความล่าช้าที่ไม่จำเป็นในการกำหนดค่ากล้องอีกครั้ง โปรดดู การค้นหาการกำหนดค่าเซสชันใหม่ - API การจัดการบัฟเฟอร์ HAL: API เหล่านี้ช่วยให้ HAL ของกล้องขอบัฟเฟอร์จากเฟรมเวิร์กของกล้องได้เมื่อจำเป็นเท่านั้น แทนที่จะเชื่อมโยงคำขอจับภาพแต่ละรายการกับบัฟเฟอร์ที่เกี่ยวข้องตลอดไปป์ไลน์ของกล้อง ซึ่งช่วยลดการใช้หน่วยความจำได้อย่างมาก
-
signalStreamFlush
: ส่งสัญญาณไปยัง HAL ว่าบริการกล้องกำลังจะดำเนินการconfigureStreams_3_5
และ HAL จะต้องส่งคืนบัฟเฟอร์ทั้งหมดของสตรีมที่กำหนด -
configureStreams_3_5
: คล้ายกับICameraDevice3.4.configureStreams
แต่นอกจากนี้ยังมีตัวนับstreamConfigCounter
เพื่อตรวจสอบเงื่อนไขการแข่งขันระหว่างการเรียกใช้configureStreams_3_5
กับsignalStreamFlush
-
การอัปเดตสำหรับ ICameraDeviceCallback
:
-
requestStreamBuffers
: การเรียกกลับแบบซิงโครนัสที่ HAL ของกล้องเรียกเพื่อขอบัฟเฟอร์จากเซิร์ฟเวอร์กล้อง โปรดดูrequestStreamBuffers
-
returnStreamBuffers
: การเรียกกลับแบบซิงค์สําหรับ HAL ของกล้องเพื่อส่งบัฟเฟอร์เอาต์พุตกลับไปยังเซิร์ฟเวอร์กล้อง โปรดดูreturnStreamBuffers
3.4
ระบบจะเพิ่มคีย์ต่อไปนี้ลงในข้อมูลเมตาของกล้องใน Android 10
- รูปแบบรูปภาพ
ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
ANDROID_SCALER_AVAILABLE_FORMATS_Y8
- แท็กข้อมูลเมตาของกล้อง
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
- ความสามารถ
-
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
-
- ค่าสําหรับ
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
คีย์ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
- การกำหนดค่าสตรีมความลึกแบบไดนามิกที่ใช้ได้
ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
- การกําหนดค่าสตรีม HEIC ที่พร้อมใช้งาน
-
ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT
-
โมดูลกล้อง
โมดูลกล้องเวอร์ชันต่อไปนี้ได้รับการอัปเดตใน Android 10
2.5
- เพิ่มเมธอด
notifyDeviceStateChange
สำหรับอุปกรณ์ในการแจ้งเตือน HAL ของกล้องเมื่อการเปลี่ยนแปลงทางกายภาพ เช่น การพับ ส่งผลต่อกล้องและการกำหนดเส้นทาง
2.4
- อุปกรณ์ที่เปิดตัวด้วย API ระดับ 29 ขึ้นไปต้องรายงาน
true
สำหรับisTorchModeSupported
Android 9
เวอร์ชัน Android 9 มีการอัปเดตต่อไปนี้สำหรับอินเทอร์เฟซ HAL และ API2 ของกล้อง
API กล้องถ่ายรูป
- เปิดตัว Multi-Camera API เพื่อรองรับอุปกรณ์ที่มีกล้องหลายตัวซึ่งหันไปในทิศทางเดียวกันได้ดียิ่งขึ้น ซึ่งจะเปิดใช้ฟีเจอร์ต่างๆ เช่น โบเก้และการซูมอย่างราบรื่น ซึ่งช่วยให้แอปดูกล้องหลายตัวในอุปกรณ์เป็นหน่วยตรรกะ (กล้องตรรกะ) หน่วยเดียวได้ นอกจากนี้ คุณยังส่งคำขอจับภาพไปยังอุปกรณ์กล้องแต่ละเครื่องที่รวมอยู่ในกล้องเสมือนหนึ่งๆ ได้ด้วย โปรดดู การรองรับกล้องหลายตัว
- แนะนำพารามิเตอร์เซสชัน พารามิเตอร์เซสชันคือกลุ่มย่อยของพารามิเตอร์การบันทึกที่ใช้ได้ ซึ่งอาจทําให้การประมวลผลล่าช้าอย่างรุนแรงเมื่อแก้ไข ค่าใช้จ่ายเหล่านี้จะลดลงได้หากไคลเอ็นต์ส่งค่าเริ่มต้นระหว่างการเริ่มต้นเซสชันการบันทึก ดูพารามิเตอร์เซสชัน
- เพิ่มคีย์ข้อมูลระบบกันภาพสั่นแบบออปติคัล (OIS) สำหรับระบบกันภาพสั่นและเอฟเฟกต์ระดับแอป โปรดดู
STATISTICS_OIS_SAMPLES
- เพิ่มการรองรับแฟลชภายนอก โปรดดู
CONTROL_AE_MODE_ON_EXTERNAL_FLASH
- เพิ่ม Intent ติดตามการเคลื่อนไหวใน
CAPTURE_INTENT
โปรดดูCONTROL_CAPTURE_INTENT_MOTION_TRACKING
- เลิกใช้งาน
LENS_RADIAL_DISTORTION
และเพิ่มLENS_DISTORTION
แทน - เพิ่มโหมดการแก้ไขการบิดเบือนใน
CaptureRequest
โปรดดูDISTORTION_CORRECTION_MODE
- เพิ่มการรองรับกล้อง USB/UVC ภายนอกในอุปกรณ์ที่รองรับ โปรดดู
INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL
HAL ของกล้อง
3.4
การอัปเดตของ ICameraDeviceSession
-
configureStreams_3_4
: เพิ่มการรองรับsessionParameters
และกล้องตรรกะ -
processCaptureRequest_3_4
: เพิ่มการรองรับการระบุรหัสกล้องจริงในโครงสร้างสตรีม
ข้อมูลอัปเดตเกี่ยวกับ ICameraDeviceCallback
-
processCaptureResult_3_4
: เพิ่มข้อมูลเมตาของกล้องจริงในผลการจับภาพ
3.3
ระบบจะเพิ่มคีย์ต่อไปนี้ลงในข้อมูลเมตาของกล้องใน Android 9
- ความสามารถ
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
- แท็กข้อมูลเมตาของกล้อง
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
Android 8.0 เปิดตัว Treble เมื่อใช้ Treble การใช้งาน HAL ของกล้องของผู้ให้บริการต้องเป็น Binder นอกจากนี้ Android 8.0 ยังมีการเพิ่มประสิทธิภาพที่สำคัญต่อไปนี้สำหรับบริการกล้อง
- แพลตฟอร์มที่แชร์: เปิดใช้แพลตฟอร์มหลายรายการที่ใช้
OutputConfiguration
เดียวกัน - System API สำหรับโหมดกล้องที่กำหนดเอง
onCaptureQueueEmpty
ดูข้อมูลเพิ่มเติมเกี่ยวกับฟีเจอร์เหล่านี้ได้ที่ส่วนด้านล่าง
พื้นผิวที่แชร์
ฟีเจอร์นี้ช่วยให้บัฟเฟอร์เพียง 1 ชุดเท่านั้นที่จะกระตุ้นเอาต์พุต 2 เอาต์พุต เช่น พรีวิวและการเข้ารหัสวิดีโอ ซึ่งจะทำให้พลังงานและการใช้หน่วยความจำลดลง หากต้องการรองรับฟีเจอร์นี้ ผู้ผลิตอุปกรณ์ต้องตรวจสอบว่าการใช้งาน HAL ของกล้องและ HAL ของ gralloc สามารถสร้างบัฟเฟอร์ gralloc ที่ใช้โดยผู้บริโภคหลายราย (เช่น คอมโพเซอร์ฮาร์ดแวร์/GPU และโปรแกรมเปลี่ยนรหัสวิดีโอ) แทนที่จะเป็นผู้บริโภคเพียงรายเดียว บริการกล้องจะส่ง Flag การใช้งานของผู้บริโภคไปยัง HAL ของกล้องและ HAL ของ gralloc โดย HAL ดังกล่าวจะต้องจัดสรรบัฟเฟอร์ประเภทที่เหมาะสม หรือ HAL ของกล้องต้องแสดงข้อผิดพลาดว่าระบบไม่รองรับการรวมผู้บริโภคนี้
ดูรายละเอียดเพิ่มเติมได้ในเอกสารสำหรับนักพัฒนาซอฟต์แวร์
enableSurfaceSharing
System API สำหรับโหมดกล้องที่กำหนดเอง
API กล้องสาธารณะจะกำหนดโหมดการทำงาน 2 โหมด ได้แก่ การบันทึกแบบปกติและแบบจำกัดความเร็วสูง แต่มีความหมายต่างกันพอสมควร ตัวอย่างเช่น โหมดความเร็วสูงจะจำกัดให้เอาต์พุตเฉพาะสูงสุด 2 เอาต์พุตพร้อมกัน OEM หลายรายแสดงความสนใจในการกำหนดโหมดที่กำหนดเองอื่นๆ สำหรับความสามารถเฉพาะฮาร์ดแวร์ ในโหมดดังกล่าว โหมดจะเป็นเพียงจำนวนเต็มที่ส่งไปยัง configure_streams
โปรดดูข้อมูลต่อไปนี้
hardware/camera/device/3.2/ICameraDeviceSession#configurestreams
ฟีเจอร์นี้มีการเรียกใช้ API ของระบบที่แอปกล้อง OEM สามารถใช้เพื่อเปิดใช้โหมดที่กำหนดเอง โหมดเหล่านี้ต้องเริ่มต้นที่ค่าจำนวนเต็ม 0x8000 เพื่อหลีกเลี่ยงความขัดแย้งกับโหมดในอนาคตที่เพิ่มลงใน API สาธารณะ
หากต้องการรองรับฟีเจอร์นี้ OEM เพียงต้องเพิ่มโหมดใหม่ลงใน HAL ซึ่งจะทริกเกอร์โดยจำนวนเต็มนี้ที่ส่งไปยัง HAL ใน configure_streams จากนั้นให้แอปกล้องที่กําหนดเองใช้ API ของระบบ
ชื่อเมธอดคือ
android.hardware.camera2.CameraDevice#createCustomCaptureSession
โปรดดูข้อมูลต่อไปนี้
frameworks/base/core/java/android/hardware/camera2/CameraDevice
onCaptureQueue ว่างเปล่า
จุดประสงค์ของ API นี้คือการลดเวลาในการตอบสนองของการเปลี่ยนแปลงการควบคุม เช่น การซูม โดยปล่อยคิวคำขอให้ว่างที่สุดเท่าที่จะทำได้ onCaptureQueueEmpty
ไม่ต้องดำเนินการใดๆ กับ HAL เป็นเพียงการเพิ่มในฝั่งเฟรมเวิร์กเท่านั้น แอปที่ต้องการใช้ประโยชน์จากฟีเจอร์นี้ต้องเพิ่ม Listener ลงใน Callback ดังกล่าวและตอบสนองอย่างเหมาะสม โดยทั่วไปคือการส่งคำขอจับภาพอีกรายการไปยังอุปกรณ์กล้อง
อินเทอร์เฟซ HIDL ของกล้อง
อินเทอร์เฟซ HIDL ของกล้องเป็นการปรับปรุงอินเทอร์เฟซ HAL ของกล้องอย่างสมบูรณ์ซึ่งใช้ API ที่กําหนดโดย HIDL ที่เสถียร ฟีเจอร์และความสามารถทั้งหมดของกล้องที่เปิดตัวในเวอร์ชันเดิมล่าสุด 3.4 และ 2.4 (สำหรับโมดูลกล้อง) เป็นส่วนหนึ่งของคำจำกัดความ HIDL ด้วย
3.4
ส่วนเพิ่มเติมเล็กน้อยในข้อมูลเมตาที่รองรับและการเปลี่ยนแปลงการรองรับ data_space
- เพิ่มข้อมูลเมตาแบบคงที่
ANDROID_SENSOR_OPAQUE_RAW_SIZE
เป็นข้อมูลที่ต้องระบุ หากระบบรองรับรูปแบบRAW_OPAQUE
- เพิ่ม
ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
ข้อมูลเมตาแบบคงที่ เป็นข้อมูลที่ต้องระบุหากระบบรองรับรูปแบบ RAW - เปลี่ยนช่อง
camera3_stream_t data_space
เป็นคำจำกัดความที่มีความยืดหยุ่นมากขึ้นโดยใช้คำจำกัดความเวอร์ชัน 0 ของการเข้ารหัสพื้นที่ข้อมูล - การเพิ่มข้อมูลเมตาทั่วไปที่ใช้ได้กับ HALv3.2 ขึ้นไปมีดังนี้
-
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
การแก้ไขเล็กน้อยของ HAL ความสามารถที่ขยายการให้บริการ
- การอัปเดต API สำหรับการประมวลผล OPAQUE และ YUV อีกครั้ง
- การรองรับเบื้องต้นสำหรับบัฟเฟอร์เอาต์พุตความลึก
- การเพิ่มช่อง
data_space
ไปยังcamera3_stream_t
- การเพิ่มช่องการหมุนเวียนใน
camera3_stream_t
- การเพิ่มโหมดการดำเนินการกำหนดค่าสตรีม Camera3 ใน
camera3_stream_configuration_t
3.2
การแก้ไขเล็กน้อยของ HAL ความสามารถที่ขยายการให้บริการ
- เลิกใช้งาน
get_metadata_vendor_tag_ops
ให้ใช้get_vendor_tag_ops
ในcamera_common.h
แทน - เลิกใช้งาน
register_stream_buffers
บัฟเฟอร์ gralloc ทั้งหมดที่เฟรมเวิร์กมอบให้ HAL ในprocess_capture_request
อาจใหม่ได้ทุกเมื่อ - เพิ่มการรองรับผลลัพธ์บางส่วน ระบบอาจเรียกใช้
process_capture_result
หลายครั้งด้วยชุดย่อยของผลลัพธ์ที่มีอยู่ก่อนที่จะแสดงผลลัพธ์ทั้งหมด - เพิ่มเทมเพลตที่กำหนดเองลงใน
camera3_request_template
แอปอาจใช้เทมเพลตนี้เพื่อควบคุมการตั้งค่าการจับภาพโดยตรง - ปรับปรุงข้อกำหนดสตรีมแบบ 2 ทิศทางและสตรีมอินพุต
- เปลี่ยนเส้นทางการย้อนกลับของบัฟเฟอร์อินพุต ระบบจะแสดงบัฟเฟอร์ใน
process_capture_result
แทนที่จะเป็นprocess_capture_request
3.1
การแก้ไขเล็กน้อยของ HAL ความสามารถที่ขยายการให้บริการ
configure_streams
ส่ง Flag การใช้งานของผู้บริโภคไปยัง HAL- ล้างการเรียกใช้เพื่อทิ้งคำขอ/บัฟเฟอร์ที่กำลังทำงานอยู่ทั้งหมดให้เร็วที่สุดเท่าที่จะเป็นไปได้
3.0
การแก้ไขครั้งแรกของ HAL ความสามารถขยาย:
- การเปลี่ยนแปลงเวอร์ชันหลักเนื่องจาก ABI แตกต่างกันโดยสิ้นเชิง ไม่มีการเปลี่ยนแปลงความสามารถของฮาร์ดแวร์หรือรูปแบบการทํางานที่จําเป็นจาก 2.0
- อินเทอร์เฟซคิวคําขออินพุตและสตรีมได้รับการแก้ไขใหม่: เฟรมเวิร์กจะเรียก HAL ด้วยคําขอถัดไปและบัฟเฟอร์สตรีมที่อยู่ในคิวแล้ว มีการสนับสนุนเฟรมเวิร์กการซิงค์ ด้วย จำเป็นต่อการติดตั้งใช้งานที่มีประสิทธิภาพ
- ย้ายทริกเกอร์ไปยังคำขอ และย้ายการแจ้งเตือนส่วนใหญ่ไปยังผลลัพธ์
- รวม Callback ทั้งหมดไว้ในเฟรมเวิร์กไว้ในโครงสร้างเดียว และวิธีการตั้งค่าทั้งหมดรวมอยู่ในการเรียกใช้
initialize()
ครั้งเดียว - เปลี่ยนการกำหนดค่าสตรีมเป็นการเรียกใช้ครั้งเดียวเพื่อลดความซับซ้อนในการจัดการสตรีม
สตรีมแบบ 2 ทิศทางจะแทนที่โครงสร้าง
STREAM_FROM_STREAM
- ความหมายของโหมดที่จํากัดสําหรับอุปกรณ์ฮาร์ดแวร์รุ่นเก่า/จํากัด
2.0
การเปิดตัว HAL ความสามารถขยาย (Android 4.2) [camera2.h] ครั้งแรก
- เพียงพอสำหรับการใช้งาน
android.hardware.Camera
API ที่มีอยู่ - อนุญาตให้ใช้คิว ZSL ในเลเยอร์บริการกล้อง
- ไม่ได้ทดสอบฟีเจอร์ใหม่ เช่น การควบคุมการจับภาพด้วยตนเอง การจับภาพ Bayer RAW การประมวลผลข้อมูล RAW อีกครั้ง ฯลฯ
1.0
HAL กล้อง Android เริ่มต้น (Android 4.0) [camera.h]:
- แปลงจากเลเยอร์การจัดการฮาร์ดแวร์โดยตรงของ C++
- รองรับ
android.hardware.Camera
API
ประวัติเวอร์ชันของโมดูลกล้อง
ส่วนนี้ประกอบด้วยข้อมูลเกี่ยวกับเวอร์ชันของโมดูลสำหรับฮาร์ดแวร์กล้อง โดยอิงตาม camera_module_t.common.module_api_version
เลขฐานสิบหกที่มีนัยสำคัญ 2 หลักแสดงถึงเวอร์ชันหลัก และเลขฐานสิบหกที่มีนัยสำคัญน้อยที่สุดคือเวอร์ชันรอง
2.4
โมดูลกล้องเวอร์ชันนี้เพิ่มการเปลี่ยนแปลง API ต่อไปนี้
- การรองรับโหมดไฟฉาย เฟรมเวิร์กนี้จะเปิดโหมดไฟฉายสำหรับอุปกรณ์กล้องที่มีหน่วยแฟลชได้โดยไม่ต้องเปิดอุปกรณ์กล้อง อุปกรณ์กล้องมีสิทธิ์เข้าถึงหน่วยแฟลชสูงกว่าโมดูลกล้อง การเปิดตัวอุปกรณ์กล้องจะปิดไฟฉายหากเปิดใช้ผ่านอินเทอร์เฟซของโมดูล เมื่อเกิดข้อขัดแย้งเกี่ยวกับทรัพยากร เช่น มีการเรียกใช้
open()
เพื่อเปิดอุปกรณ์กล้อง โมดูล HAL ของกล้องต้องแจ้งให้เฟรมเวิร์กทราบผ่านแบ็กคอลสถานะโหมดไฟฉายว่าโหมดไฟฉายปิดอยู่ - การรองรับกล้องภายนอก (เช่น กล้อง USB แบบเสียบร้อน) การอัปเดต API จะระบุข้อมูลคงที่ของกล้องเมื่อกล้องเชื่อมต่ออยู่และพร้อมใช้งานสำหรับกล้องภายนอกแบบเสียบร้อนเท่านั้น การเรียกใช้เพื่อรับข้อมูลแบบคงที่เป็นการเรียกที่ไม่ถูกต้องเมื่อสถานะกล้องไม่ใช่
CAMERA_DEVICE_STATUS_PRESENT
เฟรมเวิร์กจะนับเฉพาะการเรียกกลับการเปลี่ยนแปลงสถานะของอุปกรณ์เพื่อจัดการรายการกล้องภายนอกที่พร้อมใช้งาน - คำแนะนำในการอนุญาโตตุลาการของกล้อง เพิ่มการรองรับการระบุจำนวนอุปกรณ์กล้องที่เปิดและใช้งานได้พร้อมกันอย่างชัดเจน หากต้องการระบุชุดค่าผสมของอุปกรณ์ที่ถูกต้อง ควรตั้งค่าช่อง
resource_cost
และconflicting_devices
ในโครงสร้างcamera_info
ที่แสดงผลโดยการเรียกget_camera_info
เสมอ - วิธีการเริ่มต้นโมดูล บริการกล้องเรียกใช้หลังจากโหลดโมดูล HAL เพื่ออนุญาตให้เริ่มต้น HAL แบบครั้งเดียว โดยระบบจะเรียกใช้เมธอดนี้ก่อนเรียกใช้เมธอดอื่นๆ ของโมดูล
2.3
เวอร์ชันของโมดูลกล้องนี้จะเพิ่มการรองรับอุปกรณ์ HAL ของกล้องเดิมแบบเปิด
เฟรมเวิร์กสามารถใช้เฟรมเวิร์กเปิดอุปกรณ์กล้องเป็นอุปกรณ์ HAL เวอร์ชันต่ำกว่าของอุปกรณ์ในกรณีที่อุปกรณ์เดียวกันรองรับ API อุปกรณ์หลายเวอร์ชัน
การเรียกใช้แบบเปิดของโมดูลฮาร์ดแวร์มาตรฐาน
(common.methods->open
) จะยังคงเปิดอุปกรณ์กล้องด้วยเวอร์ชันล่าสุดที่รองรับ ซึ่งเป็นเวอร์ชันที่แสดงอยู่ใน camera_info_t.device_version
ด้วย
2.2
เวอร์ชันนี้ของโมดูลกล้องจะเพิ่มการรองรับแท็กของผู้ให้บริการจากโมดูล และเลิกใช้งาน vendor_tag_query_ops
เวอร์ชันเก่าซึ่งก่อนหน้านี้เข้าถึงได้เฉพาะเมื่ออุปกรณ์เปิดอยู่
2.1
โมดูลกล้องเวอร์ชันนี้เพิ่มการรองรับการเรียกกลับแบบไม่พร้อมกันไปยังเฟรมเวิร์กจากโมดูล HAL ของกล้อง ซึ่งใช้เพื่อแจ้งเฟรมเวิร์กเกี่ยวกับการเปลี่ยนแปลงสถานะของโมดูลกล้อง โมดูลที่ระบุเมธอด set_callbacks()
ที่ถูกต้องต้องรายงานหมายเลขเวอร์ชันนี้เป็นอย่างน้อย
2.0
โมดูลกล้องที่รายงานหมายเลขเวอร์ชันนี้จะใช้อินเทอร์เฟซ HAL ของโมดูลกล้องเวอร์ชันที่สอง อุปกรณ์กล้องที่เปิดผ่านข้อบังคับนี้ได้อาจรองรับอินเทอร์เฟซ HAL ของอุปกรณ์กล้องเวอร์ชัน 1.0 หรือ 2.0 ฟิลด์ device_version
ของ camera_info จะถูกต้องเสมอ ส่วนฟิลด์ static_camera_characteristics
ของ camera_info
จะถูกต้องหากฟิลด์ device_version
เป็น 2.0 ขึ้นไป
1.0
โมดูลกล้องที่รายงานหมายเลขเวอร์ชันเหล่านี้จะใช้อินเทอร์เฟซ HAL ของโมดูลกล้องเวอร์ชันเริ่มต้น อุปกรณ์กล้องทั้งหมดที่เปิดผ่านข้อบังคับนี้ได้จะรองรับเฉพาะ HAL ของอุปกรณ์กล้องเวอร์ชัน 1 เท่านั้น ช่อง device_version
และ static_camera_characteristics
ของ camera_info
ไม่ถูกต้อง โมดูลและอุปกรณ์ของโมดูลนี้รองรับเฉพาะ android.hardware.Camera
API เท่านั้น