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

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

คำศัพท์

คำศัพท์ต่อไปนี้ใช้ในหน้านี้:

กล้อง API1

เฟรมเวิร์กของกล้องระดับแอพบน Android 4.4 และอุปกรณ์ที่ต่ำกว่า ซึ่งเปิดเผยผ่านคลาส android.hardware.Camera

กล้อง API2

เฟรมเวิร์กกล้องระดับแอปบนอุปกรณ์ Android 5.0 ขึ้นไป ซึ่งเปิดเผยผ่านแพ็คเกจ android.hardware.camera2

กล้อง HAL

เลเยอร์โมดูลกล้องที่ใช้งานโดยผู้จำหน่าย SoC เฟรมเวิร์กสาธารณะระดับแอปถูกสร้างขึ้นที่ด้านบนของกล้อง HAL

กล้อง HAL3.1

เวอร์ชันของอุปกรณ์กล้อง HAL ที่ออกมาพร้อมกับ Android 4.4

กล้อง HAL3.2

เวอร์ชันของอุปกรณ์กล้อง HAL ออกมาพร้อมกับ Android 5.0

กล้อง API1 CTS

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

กล้อง API2 CTS

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

เสียงแหลม

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

HIDL

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

วี.ที.เอส

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

API ของกล้อง

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

กล้อง API1

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

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

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

ในอุปกรณ์รุ่นเก่า การทดสอบ Camera API2 CTS ที่เรียกใช้จะใช้อินเทอร์เฟซและความสามารถ Camera API1 สาธารณะที่มีอยู่โดยไม่มีข้อกำหนดใหม่ ข้อบกพร่องที่เปิดเผย (และทำให้เกิดความล้มเหลวของ Camera API2 CTS) เป็นจุดบกพร่องที่มีอยู่แล้วใน Camera HAL ที่มีอยู่ของอุปกรณ์ และดังนั้นจะพบได้ในแอป Camera API1 ที่มีอยู่ เราไม่คาดว่าจะมีข้อบกพร่องมากมายในลักษณะนี้ (อย่างไรก็ตาม ข้อบกพร่องใดๆ ดังกล่าวต้องได้รับการแก้ไขเพื่อให้ผ่านการทดสอบ Camera API2 CTS)

ข้อกำหนด VTS

อุปกรณ์ที่ใช้ Android 8.0 และสูงกว่าที่มีการใช้งาน Binderized HAL จะต้องผ่าน การทดสอบ Camera VTS

กรอบกล้องแข็งตัว

เพื่อเพิ่มความปลอดภัยของเฟรมเวิร์กสื่อและกล้อง Android 7.0 จะย้ายบริการกล้องออกจากเซิร์ฟเวอร์สื่อ ตั้งแต่ Android 8.0 เป็นต้นไป Camera HAL ที่ผูกไว้แต่ละตัวจะทำงานในกระบวนการแยกจากบริการกล้อง ผู้จำหน่ายอาจต้องทำการเปลี่ยนแปลงใน HAL ของกล้อง ทั้งนี้ขึ้นอยู่กับเวอร์ชัน API และ HAL ที่ใช้งานอยู่ ส่วนต่อไปนี้ให้รายละเอียดเกี่ยวกับการเปลี่ยนแปลงทางสถาปัตยกรรมใน AP1 และ AP2 สำหรับ HAL1 และ HAL3 รวมถึงข้อกำหนดทั่วไป

การเปลี่ยนแปลงทางสถาปัตยกรรมสำหรับ API1

การบันทึกวิดีโอ API1 อาจถือว่ากล้องและตัวเข้ารหัสวิดีโอทำงานอยู่ในกระบวนการเดียวกัน เมื่อใช้ API1 บน:

• HAL3 ซึ่งบริการกล้องใช้ BufferQueue เพื่อส่งผ่านบัฟเฟอร์ระหว่างกระบวนการ ไม่จำเป็นต้องอัปเดตผู้จำหน่าย

  

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

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

  

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

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

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

• HAL1 ไม่ได้รับผลกระทบจากการย้ายบริการกล้อง และ ไม่จำเป็นต้องอัปเดตผู้ให้บริการ
• 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 สำหรับเซิร์ฟเวอร์กล้อง หากนโยบาย SELinux เฉพาะอุปกรณ์ให้สิทธิ์เซิร์ฟเวอร์มีเดียในการเรียกใช้กล้อง คุณต้องอัปเดตนโยบาย SELinux เพื่อให้สิทธิ์ที่เหมาะสมแก่เซิร์ฟเวอร์กล้อง เราไม่แนะนำให้ทำซ้ำนโยบาย SELinux ของเซิร์ฟเวอร์สื่อสำหรับเซิร์ฟเวอร์กล้อง (เนื่องจากเซิร์ฟเวอร์สื่อและเซิร์ฟเวอร์กล้องโดยทั่วไปต้องการทรัพยากรที่แตกต่างกันในระบบ) เซิร์ฟเวอร์กล้องควรมีสิทธิ์ที่จำเป็นในการใช้งานฟังก์ชันกล้องเท่านั้น และควรลบสิทธิ์ที่เกี่ยวข้องกับกล้องที่ไม่จำเป็นในเซิร์ฟเวอร์สื่อ
• การแยกระหว่าง Camera HAL และเซิร์ฟเวอร์กล้อง Android 8.0 และสูงกว่ายังแยก Camera HAL ที่ผูกไว้ในกระบวนการที่แตกต่างจากเซิร์ฟเวอร์กล้อง IPC ต้องผ่านอินเทอร์เฟซ ที่กำหนดโดย HIDL

การตรวจสอบ

สำหรับอุปกรณ์ทั้งหมดที่มีกล้องและใช้ Android 7.0 ให้ตรวจสอบการใช้งานโดยใช้ Android 7.0 CTS แม้ว่า Android 7.0 จะไม่มีการทดสอบ CTS ใหม่ที่ตรวจสอบการเปลี่ยนแปลงบริการกล้อง แต่การทดสอบ CTS ที่มีอยู่จะล้มเหลวหากคุณไม่ได้ทำการอัปเดตตามที่ระบุข้างต้น

สำหรับอุปกรณ์ทั้งหมดที่มีกล้องและใช้ Android 8.0 ขึ้นไป ให้ตรวจสอบการใช้งานของผู้จำหน่ายโดยเรียกใช้ VTS

ประวัติเวอร์ชันของกล้อง HAL

สำหรับรายการการทดสอบที่ใช้ประเมิน Android Camera HAL โปรดดู รายการตรวจสอบการทดสอบ Camera HAL

แอนดรอยด์ 10

Android 10 แนะนำการอัปเดตต่อไปนี้

API ของกล้อง

• การปรับปรุงกล้องหลายตัวที่อนุญาตให้ใช้กล้องจริงทีละตัวหรือผ่านกล้องแบบลอจิคัลที่สอดคล้องกันโดยการซ่อน ID ของกล้องจริง ดู การรองรับกล้องหลายตัว
• ความสามารถในการตรวจสอบว่ามีการสนับสนุนการกำหนดค่าเซสชันเฉพาะหรือไม่ โดยไม่ต้องเสียค่าใช้จ่ายด้านประสิทธิภาพในการสร้างเซสชันใหม่ ดู CameraDevice
• ความสามารถในการเรียกข้อมูลการกำหนดค่าสตรีมที่แนะนำสำหรับกรณีการใช้งานที่กำหนด เพื่อให้ไคลเอ็นต์ประหยัดพลังงานและมีประสิทธิภาพมากขึ้น ดู getRecommendedStreamConfigurationMap
• รองรับ รูปแบบภาพ JPEG เชิงลึก สำหรับรายละเอียดเพิ่มเติม โปรดดู ข้อกำหนดความลึกไดนามิก
• รองรับ รูปแบบภาพ HEIC ดู การสร้างภาพ HEIF
• การปรับปรุงความเป็นส่วนตัว คีย์บางอย่างจำเป็นสำหรับไคลเอ็นต์เพื่อให้มีสิทธิ์ใช้ CAMERA ก่อนจึงจะสามารถเรียกค้นจาก CameraCharacteristics ได้ ดู getKeysNeedingPermission

กล้อง HAL

เวอร์ชัน Camera HAL ต่อไปนี้ได้รับการอัปเดตใน Android 10

3.5

ICameraDevice

• getPhysicalCameraCharacteristics : ข้อมูลกล้องคงที่สำหรับ ID กล้องจริงที่สำรองอุปกรณ์กล้องแบบลอจิคัล ดู การรองรับกล้องหลายตัว
• 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

แอนดรอยด์ 9

การเปิดตัว Android 9 แนะนำการอัปเดตต่อไปนี้สำหรับกล้อง API2 และอินเทอร์เฟซ HAL

API ของกล้อง

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

แอนดรอยด์ 8.0

การเปิดตัว Android 8.0 แนะนำ Treble เมื่อใช้ Treble การใช้งาน Camera HAL ของผู้จำหน่ายจะต้องถูก ผูกมัด Android 8.0 ยังมีการปรับปรุงที่สำคัญเหล่านี้สำหรับบริการกล้อง:

• พื้นผิวที่ใช้ร่วมกัน: เปิดใช้งานหลายพื้นผิวที่ใช้ร่วมกัน OutputConfiguration
• API ระบบสำหรับโหมดกล้องแบบกำหนดเอง
• onCaptureQueueEmpty

ดูส่วนด้านล่างสำหรับข้อมูลเพิ่มเติมเกี่ยวกับคุณสมบัติเหล่านี้

พื้นผิวที่ใช้ร่วมกัน

คุณลักษณะนี้ช่วยให้บัฟเฟอร์เพียงชุดเดียวขับเคลื่อนสองเอาต์พุต เช่น การดูตัวอย่างและการเข้ารหัสวิดีโอ ซึ่งช่วยลดการใช้พลังงานและหน่วยความจำ เพื่อรองรับคุณสมบัตินี้ ผู้ผลิตอุปกรณ์จำเป็นต้องตรวจสอบให้แน่ใจว่าการใช้งาน HAL ของกล้องและ gralloc HAL สามารถสร้างบัฟเฟอร์ granloc ที่ใช้โดยผู้ใช้หลายรายที่แตกต่างกัน (เช่น ตัวเขียนฮาร์ดแวร์/GPU และตัวเข้ารหัสวิดีโอ) แทนที่จะเป็นผู้ใช้เพียงรายเดียว บริการกล้องจะส่งการตั้งค่าสถานะการใช้งานของผู้บริโภคไปยังกล้อง HAL และ Gralloc HAL; พวกเขาจำเป็นต้องจัดสรรบัฟเฟอร์ให้ถูกประเภท หรือกล้อง HAL ต้องส่งคืนข้อผิดพลาดที่ไม่รองรับการรวมผู้บริโภคนี้

ดูเอกสารประกอบสำหรับนักพัฒนา enableSurfaceSharing สำหรับรายละเอียดเพิ่มเติม

API ระบบสำหรับโหมดกล้องแบบกำหนดเอง

API ของกล้องสาธารณะกำหนดโหมดการทำงานสองโหมด: การบันทึกความเร็วสูงแบบปกติและแบบจำกัด พวกเขามีความหมายที่แตกต่างกันพอสมควร ตัวอย่างเช่น โหมดความเร็วสูงถูกจำกัดไว้สูงสุดสองเอาต์พุตเฉพาะพร้อมกัน OEM หลายรายแสดงความสนใจในการกำหนดโหมดแบบกำหนดเองอื่นๆ สำหรับความสามารถเฉพาะของฮาร์ดแวร์ ภายใต้ประทุน โหมดเป็นเพียงจำนวนเต็มที่ส่งไปยัง configure_streams ดู: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams

คุณลักษณะนี้ประกอบด้วยการเรียก API ของระบบที่แอปกล้อง OEM สามารถใช้เพื่อเปิดใช้งานโหมดกำหนดเองได้ โหมดเหล่านี้ต้องเริ่มต้นที่ค่าจำนวนเต็ม 0x8000 เพื่อหลีกเลี่ยงความขัดแย้งกับโหมดในอนาคตที่เพิ่มไปยัง API สาธารณะ

เพื่อรองรับคุณลักษณะนี้ OEM จำเป็นต้องเพิ่มโหมดใหม่ไปยัง HAL ของตน ซึ่งเรียกใช้งานโดยจำนวนเต็มนี้ที่ส่งผ่านไปยัง HAL บน configuration_streams จากนั้นให้แอปกล้องที่กำหนดเองใช้ API ของระบบ

ชื่อเมธอดคือ android.hardware.camera2.CameraDevice#createCustomCaptureSession ดู: frameworks/base/core/java/android/hardware/camera2/CameraDevice

บนCaptureQueueEmpty

จุดประสงค์ของ API นี้คือเพื่อลดเวลาแฝงของการเปลี่ยนแปลงการควบคุม เช่น การซูม โดยทำให้คิวคำขอว่างที่สุด onCaptureQueueEmpty ไม่ต้องทำงาน HAL; มันเป็นการเพิ่มด้านเฟรมเวิร์กเท่านั้น แอปพลิเคชันที่ต้องการใช้ประโยชน์จากจำเป็นต้องเพิ่มฟังการเรียกกลับนั้นและตอบสนองอย่างเหมาะสม โดยทั่วไปคือการส่งคำขอจับภาพอีกครั้งไปยังอุปกรณ์กล้อง

อินเทอร์เฟซกล้อง HIDL

อินเทอร์เฟซ Camera HIDL เป็นการยกเครื่องใหม่ของอินเทอร์เฟซ Camera 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 ของการเข้ารหัส dataspace
• การเพิ่มข้อมูลเมตาทั่วไปซึ่งมีให้ใช้สำหรับ 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 แอปพลิเคชันอาจใช้เทมเพลตนี้เพื่อควบคุมการตั้งค่าการจับภาพโดยตรง
• ทำใหม่ข้อมูลจำเพาะของกระแสข้อมูลแบบสองทิศทางและอินพุต
• เปลี่ยนเส้นทางกลับของบัฟเฟอร์อินพุต บัฟเฟอร์จะถูกส่งคืนใน process_capture_result แทน process_capture_request

3.1

การแก้ไขเล็กน้อยของ HAL ที่เพิ่มความสามารถ:

• configure_streams ส่งการตั้งค่าสถานะการใช้งานของผู้บริโภคไปยัง HAL
• ล้างสายเพื่อยกเลิกคำขอ/บัฟเฟอร์ในเที่ยวบินทั้งหมดให้เร็วที่สุด

3.0

การแก้ไขครั้งแรกของ HAL ที่เพิ่มความสามารถ:

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

2.0

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

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

1.0

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

• แปลงจากเลเยอร์นามธรรมของ C++ CameraHardwareInterface
• รองรับ android.hardware.Camera API

ประวัติรุ่นของโมดูลกล้อง

ส่วนนี้ประกอบด้วยข้อมูลการกำหนดเวอร์ชันของโมดูลสำหรับโมดูลฮาร์ดแวร์ของ Camera ตาม camera_module_t.common.module_api_version เลขฐานสิบหกที่มีนัยสำคัญมากที่สุดสองหลักแสดงถึงเวอร์ชันหลัก และเลขฐานสิบหกที่มีนัยสำคัญน้อยที่สุดสองหลักแสดงถึงเวอร์ชันรอง

2.4

รุ่นโมดูลกล้องนี้เพิ่มการเปลี่ยนแปลง API ต่อไปนี้:

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

2.3

รุ่นโมดูลกล้องนี้เพิ่มการรองรับอุปกรณ์ HAL ของกล้องรุ่นเก่าแบบเปิด เฟรมเวิร์กสามารถใช้เพื่อเปิดอุปกรณ์กล้องเป็นอุปกรณ์ HAL เวอร์ชันต่ำกว่า อุปกรณ์ HAL หากอุปกรณ์เดียวกันสามารถรองรับเวอร์ชัน API ของอุปกรณ์ได้หลายเวอร์ชัน open call ของโมดูลฮาร์ดแวร์มาตรฐาน ( 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 เท่านั้นที่รองรับโดยโมดูลนี้และอุปกรณ์