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

จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ

หน้านี้จะแสดงรายละเอียดความแตกต่างของเวอร์ชันใน HAL, API ของกล้อง และการทดสอบชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) ที่เกี่ยวข้อง นอกจากนี้ ยังครอบคลุมการเปลี่ยนแปลงเชิงโครงสร้างหลายประการที่ทําขึ้นเพื่อเพิ่มความแข็งแกร่งและรักษาความปลอดภัยให้กับเฟรมเวิร์กกล้องใน Android 7.0, การเปลี่ยนไปใช้ Treble ใน Android 8.0 และการอัปเดตที่ผู้ให้บริการต้องทําเพื่อรองรับการเปลี่ยนแปลงเหล่านี้ในการใช้งานกล้อง

คำศัพท์

คําศัพท์ที่ใช้ในหน้านี้มีดังนี้

Camera API1

เฟรมเวิร์กกล้องระดับแอปในอุปกรณ์ 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

Camera API1 CTS

ชุดการทดสอบ CTS ของกล้องที่ทำงานบน Camera API1

Camera API2 CTS

ชุดการทดสอบ CTS ของกล้องเพิ่มเติมที่ทำงานบน Camera API2

เสียงแหลม

แยกการติดตั้งใช้งานของผู้ให้บริการ (ซอฟต์แวร์ระดับล่างเฉพาะอุปกรณ์ที่เขียนโดยผู้ผลิตชิป) ออกจากเฟรมเวิร์กระบบปฏิบัติการ Android ผ่านอินเทอร์เฟซผู้ให้บริการแบบใหม่

HIDL

ภาษาคำจำกัดความอินเทอร์เฟซ HAL ที่เปิดตัวพร้อมกับ Treble และใช้เพื่อระบุอินเทอร์เฟซระหว่าง HAL กับผู้ใช้

VTS

ชุดทดสอบของผู้ให้บริการเปิดตัวพร้อมกับ Treble

Camera API

Android มี API กล้องต่อไปนี้

Camera API1

Android 5.0 ได้เลิกใช้งาน Camera API1 แล้ว และเราจะเลิกใช้งานต่อไปเนื่องจากการพัฒนาแพลตฟอร์มใหม่มุ่งเน้นที่ Camera API2 อย่างไรก็ตาม ระยะเวลาในการหยุดให้บริการจะนานพอสมควร และ Android เวอร์ชันต่างๆ จะยังคงรองรับแอป Camera API1 ต่อไปอีกระยะหนึ่ง โดยเฉพาะอย่างยิ่ง เราจะยังคงให้การสนับสนุนสำหรับสิ่งต่อไปนี้

• อินเทอร์เฟซ Camera API1 สําหรับแอป แอปกล้องที่สร้างจาก Camera API1 ควรทำงานได้เช่นเดียวกับในอุปกรณ์ที่ใช้ Android เวอร์ชันที่ต่ำกว่า
• เวอร์ชัน HAL ของกล้อง รวมถึงรองรับ Camera HAL1.0

Camera API2

เฟรมเวิร์ก Camera API2 จะแสดงการควบคุมกล้องในระดับล่างให้กับแอป ซึ่งรวมถึงโฟลว์การถ่ายแบบต่อเนื่อง/สตรีมมิงแบบไม่ทำสำเนาที่มีประสิทธิภาพและการควบคุมระดับเฟรมของการรับแสง อัตราขยาย อัตราขยายของการปรับสมดุลสีขาว การเปลี่ยนสี การตัดสัญญาณรบกวน การปรับความคมชัด และอื่นๆ ดูรายละเอียดได้ในวิดีโอ ภาพรวมของ 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 ที่มีอยู่จะพบข้อบกพร่องดังกล่าว เราคาดว่าจะพบข้อบกพร่องลักษณะนี้ไม่มากนัก (แต่ต้องแก้ไขข้อบกพร่องดังกล่าวเพื่อผ่านการทดสอบ CTS ของ Camera API2)

ข้อกำหนด VTS

อุปกรณ์ที่ใช้ Android 8.0 ขึ้นไปที่มีการใช้งาน HAL แบบ Binderized ต้องผ่านการทดสอบ VTS ของกล้อง

การเพิ่มความปลอดภัยให้เฟรมเวิร์กกล้อง

Android 7.0 ย้ายบริการกล้องออกจาก mediaserver เพื่อเพิ่มความแข็งแกร่งให้กับความปลอดภัยของเฟรมเวิร์กสื่อและกล้อง ตั้งแต่ Android 8.0 เป็นต้นไป Camera HAL แบบ Binderized แต่ละรายการจะทำงานในกระบวนการแยกต่างหากจากบริการกล้อง ผู้ให้บริการอาจต้องทําการเปลี่ยนแปลงใน 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 อาจจัดเก็บตัวแฮนเดิลบัฟเฟอร์ B ในครั้งถัดไปที่ HAL ได้รับ
• อัปเดตนโยบาย SELinux สำหรับ cameraserver หากนโยบาย SELinux สำหรับอุปกรณ์เฉพาะให้สิทธิ์ mediaserver ในการใช้งานกล้อง คุณจะต้องอัปเดตนโยบาย SELinux เพื่อให้สิทธิ์ที่เหมาะสมแก่ cameraserver เราขอแนะนำไม่ให้ทำซ้ำนโยบาย SELinux ของ mediaserver สำหรับ cameraserver (เนื่องจากโดยทั่วไปแล้ว mediaserver และ cameraserver ต้องใช้ทรัพยากรที่แตกต่างกันในระบบ) Cameraserver ควรมีเฉพาะสิทธิ์ที่จําเป็นต่อฟังก์ชันการทํางานของกล้อง และควรนําสิทธิ์ที่ไม่จําเป็นซึ่งเกี่ยวข้องกับกล้องใน Mediaserver ออก
• การแยกระหว่าง HAL ของกล้องกับเซิร์ฟเวอร์กล้อง Android 8.0 ขึ้นไปจะแยก HAL ของกล้องที่ใช้ Binder ไว้ในกระบวนการที่แตกต่างจาก 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: เมธอดที่บอกเฟรมเวิร์กกล้องว่าจำเป็นต้องกำหนดค่าสตรีมใหม่ทั้งหมดสำหรับค่าพารามิเตอร์เซสชันใหม่หรือไม่ วิธีนี้จะช่วยหลีกเลี่ยงความล่าช้าที่ไม่จำเป็นในการกำหนดค่ากล้องอีกครั้ง ดูหัวข้อ คำถามเกี่ยวกับการกำหนดค่าเซสชันใหม่
• HAL API การจัดการบัฟเฟอร์: 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

ดูข้อมูลเพิ่มเติมเกี่ยวกับฟีเจอร์เหล่านี้ได้ที่ส่วนด้านล่าง

พื้นผิวที่แชร์

ฟีเจอร์นี้ช่วยให้บัฟเฟอร์ชุดเดียวขับเคลื่อนเอาต์พุต 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

onCaptureQueueEmpty

วัตถุประสงค์ของ 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
• การเรียกใช้ flush เพื่อยกเลิกคำขอ/บัฟเฟอร์ที่ส่งอยู่ทั้งหมดโดยเร็วที่สุด

3.0

การแก้ไขครั้งแรกของ HAL ความสามารถขยาย:

• การเปลี่ยนแปลงเวอร์ชันหลักเนื่องจาก ABI แตกต่างกันโดยสิ้นเชิง ไม่มีการเปลี่ยนแปลงความสามารถของฮาร์ดแวร์หรือรูปแบบการทํางานที่จําเป็นจาก 2.0
• อินเทอร์เฟซคิวคําขออินพุตและสตรีมได้รับการแก้ไขใหม่: เฟรมเวิร์กเรียก HAL ด้วยคําขอถัดไปและบัฟเฟอร์สตรีมที่อยู่ในคิวแล้ว รองรับเฟรมเวิร์กการซิงค์ ซึ่งจําเป็นสําหรับการใช้งานที่มีประสิทธิภาพ
• ย้ายทริกเกอร์ไปยังคำขอ และย้ายการแจ้งเตือนส่วนใหญ่ไปยังผลลัพธ์
• รวมการเรียกกลับทั้งหมดไว้ในเฟรมเวิร์กเป็นโครงสร้างเดียว และรวมวิธีการตั้งค่าทั้งหมดไว้ในinitialize()การเรียกใช้ครั้งเดียว
• เปลี่ยนการกำหนดค่าสตรีมเป็นการเรียกใช้ครั้งเดียวเพื่อลดความซับซ้อนในการจัดการสตรีม สตรีมแบบ 2 ทิศทางจะแทนที่คอนสตรัคต์ STREAM_FROM_STREAM
• ความหมายของโหมดที่จํากัดสําหรับอุปกรณ์ฮาร์ดแวร์รุ่นเก่า/จํากัด

2.0

การเปิดตัว HAL ความสามารถขยาย (Android 4.2) [camera2.h] ครั้งแรก

• เพียงพอสําหรับการติดตั้งใช้งาน android.hardware.Camera API ที่มีอยู่
• อนุญาตให้ใช้คิว ZSL ในเลเยอร์บริการกล้อง
• ไม่ได้ทดสอบฟีเจอร์ใหม่ เช่น การควบคุมการจับภาพด้วยตนเอง การจับภาพ RAW แบบ Bayer การประมวลผลข้อมูล RAW อีกครั้ง ฯลฯ

1.0

HAL กล้อง Android เริ่มต้น (Android 4.0) [camera.h]:

• แปลงจากเลเยอร์การจัดการฮาร์ดแวร์โดยตรงของ C++
• รองรับ android.hardware.Camera API

ประวัติเวอร์ชันของโมดูลกล้อง

ส่วนนี้ประกอบด้วยข้อมูลเกี่ยวกับเวอร์ชันของโมดูลสำหรับฮาร์ดแวร์กล้อง โดยอิงตาม camera_module_t.common.module_api_version ตัวเลขฐาน 16 2 หลักที่มีนัยสำคัญที่สุดแสดงถึงเวอร์ชันหลัก และตัวเลขฐาน 16 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 ของโมดูลกล้องเวอร์ชันที่ 2 อุปกรณ์กล้องที่เปิดผ่านข้อบังคับนี้ได้อาจรองรับอินเทอร์เฟซ 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 เท่านั้น