การรองรับเวอร์ชันของกล้อง

หน้านี้แสดงรายละเอียดของเวอร์ชันที่แตกต่างกันใน 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 เพื่อส่งบัฟเฟอร์ระหว่างกระบวนการ ไม่จำเป็นต้องอัปเดตผู้ให้บริการ

  

  รูปที่ 1 แพ็กเกจกล้องและสื่อของ Android 7.0 ใน API1 บน HAL3

• HAL1 ซึ่งรองรับการส่งข้อมูลเมตาในบัฟเฟอร์วิดีโอ ผู้ให้บริการต้องอัปเดต HAL เพื่อใช้ kMetadataBufferTypeNativeHandleSource (Android 7.0 ไม่รองรับ kMetadataBufferTypeCameraSource อีกต่อไป)

  

  รูปที่ 2 กองซ้อนกล้องและสื่อของ Android 7.0 ใน API1 บน HAL1

การเปลี่ยนแปลงสถาปัตยกรรมสําหรับ API2

สำหรับ API2 ใน HAL1 หรือ HAL3 BufferQueue จะส่งบัฟเฟอร์เพื่อให้เส้นทางเหล่านั้นทำงานต่อไป สถาปัตยกรรม Android 7.0 สำหรับ API2 ในอุปกรณ์ต่อไปนี้

• HAL1 ไม่ได้รับผลกระทบจากการย้ายข้อมูล cameraservice และไม่จำเป็นต้องอัปเดตผู้ให้บริการ
• HAL3 ได้รับผลกระทบ แต่ไม่จําเป็นต้องอัปเดตผู้ให้บริการ

  

  รูปที่ 3 กองซ้อนกล้องและสื่อของ Android 7.0 ใน API2 บน 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

หมายเหตุ: ในรุ่น Android 8.1 แอปต้องติดตั้งไว้ล่วงหน้าในอิมเมจระบบจึงจะเข้าถึง API นี้ได้

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 ต่อไปนี้

1. การรองรับโหมดไฟฉาย เฟรมเวิร์กนี้จะเปิดโหมดไฟฉายสำหรับอุปกรณ์กล้องที่มีหน่วยแฟลชได้โดยไม่ต้องเปิดอุปกรณ์กล้อง อุปกรณ์กล้องมีสิทธิ์เข้าถึงหน่วยแฟลชสูงกว่าโมดูลกล้อง การเปิดตัวอุปกรณ์กล้องจะปิดไฟฉายหากเปิดใช้ผ่านอินเทอร์เฟซของโมดูล เมื่อเกิดข้อขัดแย้งเกี่ยวกับทรัพยากร เช่น มีการเรียกใช้ open() เพื่อเปิดอุปกรณ์กล้อง โมดูล HAL ของกล้องต้องแจ้งให้เฟรมเวิร์กทราบผ่านแบ็กคอลสถานะโหมดไฟฉายว่าโหมดไฟฉายปิดอยู่
2. การรองรับกล้องภายนอก (เช่น กล้อง USB แบบเสียบร้อน) การอัปเดต API จะระบุข้อมูลคงที่ของกล้องเมื่อกล้องเชื่อมต่ออยู่และพร้อมใช้งานสำหรับกล้องภายนอกแบบเสียบร้อนเท่านั้น การเรียกใช้เพื่อรับข้อมูลแบบคงที่เป็นการเรียกที่ไม่ถูกต้องเมื่อสถานะกล้องไม่ใช่ CAMERA_DEVICE_STATUS_PRESENT เฟรมเวิร์กจะนับเฉพาะการเรียกกลับการเปลี่ยนแปลงสถานะของอุปกรณ์เพื่อจัดการรายการกล้องภายนอกที่พร้อมใช้งาน
3. คำแนะนำในการอนุญาโตตุลาการของกล้อง เพิ่มการรองรับการระบุจำนวนอุปกรณ์กล้องที่เปิดและใช้งานได้พร้อมกันอย่างชัดเจน หากต้องการระบุชุดค่าผสมของอุปกรณ์ที่ถูกต้อง ควรตั้งค่าช่อง resource_cost และ conflicting_devices ในโครงสร้าง camera_info ที่แสดงผลโดยการเรียก get_camera_info เสมอ
4. วิธีการเริ่มต้นโมดูล บริการกล้องเรียกใช้หลังจากโหลดโมดูล 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 เท่านั้น