หน้านี้ให้รายละเอียดความแตกต่างของเวอร์ชันใน 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 ของกล้องเพิ่มเติมที่ทำงานบน Camera API2
- เสียงแหลม
- แยกการใช้งานของผู้จำหน่าย (ซอฟต์แวร์ระดับล่างเฉพาะอุปกรณ์ที่เขียนโดยผู้ผลิตซิลิคอน) ออกจากเฟรมเวิร์กระบบปฏิบัติการ Android ผ่านอินเทอร์เฟซใหม่ของผู้จำหน่าย
- HIDL
- ภาษานิยามอินเทอร์เฟซ HAL ที่ นำมาใช้กับเสียงแหลมและใช้เพื่อระบุอินเทอร์เฟซระหว่าง HAL และผู้ใช้
- VTS
- แนะนำ ชุดทดสอบผู้ขายพร้อม กับ Treble
API ของกล้อง
Android มี API ของกล้องดังต่อไปนี้
กล้อง API1
Camera API1 ที่เลิกใช้ Android 5.0 แล้ว ซึ่งยังคงถูกเลิกใช้เนื่องจากการพัฒนาแพลตฟอร์มใหม่มุ่งเน้นไปที่ Camera API2 อย่างไรก็ตาม ระยะการเลิกใช้งานจะยาวนาน และรุ่น Android จะยังคงรองรับแอป Camera API1 ต่อไปในบางครั้ง โดยเฉพาะอย่างยิ่ง การสนับสนุนยังคงดำเนินต่อไปสำหรับ:
- อินเทอร์เฟซ Camera API1 สำหรับแอป แอปกล้องถ่ายรูปที่สร้างขึ้นจาก Camera API1 ควรทำงานเหมือนกับที่ทำกับอุปกรณ์ที่ใช้ Android เวอร์ชันที่ต่ำกว่า
- รุ่นกล้อง HAL รวมการรองรับ Camera HAL1.0
กล้อง 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 ที่รองรับนั้นมีให้ใช้งานตามแฟล็กคุณลักษณะต่อไปนี้เพื่ออนุญาตให้ Google Play กรองแอปกล้อง Camera API2 ของ Google Play
-
android.hardware.camera.hardware_level.full
-
android.hardware.camera.capability.raw
-
android.hardware.camera.capability.manual_sensor
-
android.hardware.camera.capability.manual_post_processing
ข้อกำหนด 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 ขึ้นไปที่มีการใช้งาน 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 ของเซิร์ฟเวอร์มีเดียสำหรับเซิร์ฟเวอร์กล้อง (เนื่องจากเซิร์ฟเวอร์มีเดียและเซิร์ฟเวอร์ของกล้องมักต้องการทรัพยากรที่แตกต่างกันในระบบ) Cameraserver ควรมีสิทธิ์ที่จำเป็นต่อการทำงานของกล้องเท่านั้น และควรลบการอนุญาตที่เกี่ยวข้องกับกล้องที่ไม่จำเป็นใน mediaserver
- การแยกระหว่าง 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
Android 10
Android 10 แนะนำการอัปเดตต่อไปนี้
Camera API
- การปรับปรุงกล้องหลายตัวที่อนุญาตให้ใช้กล้องจริงทีละตัวหรือผ่านกล้องลอจิกที่เกี่ยวข้องโดยการซ่อน ID ของกล้องจริง ดู การสนับสนุนกล้องหลาย ตัว
- ความสามารถในการตรวจสอบว่าการกำหนดค่าเซสชันเฉพาะได้รับการสนับสนุนโดยไม่มีค่าใช้จ่ายด้านประสิทธิภาพในการสร้างเซสชันใหม่ โปรดดู
CameraDevice
- ความสามารถในการดึงข้อมูลการกำหนดค่าสตรีมที่แนะนำสำหรับกรณีการใช้งานที่กำหนด เพื่อทำให้ไคลเอ็นต์มีประสิทธิภาพและประสิทธิภาพด้านพลังงานมากขึ้น ดู
getRecommendedStreamConfigurationMap
- รองรับ รูปแบบภาพ JPEG ความลึก สำหรับรายละเอียดเพิ่มเติม โปรดดูข้อกำหนด Dynamic Depth
- รองรับ รูปแบบภาพ 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
Android 9
การเปิดตัว Android 9 จะแนะนำการอัปเดตต่อไปนี้สำหรับอินเทอร์เฟซ API2 และ HAL ของกล้อง
Camera 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
: เพิ่มการรองรับการรวม ID ของกล้องจริงในโครงสร้างสตรีม
การอัปเดต 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 แนะนำเสียงแหลม เมื่อใช้เสียงแหลม การใช้งาน Camera HAL ของผู้ขายจะต้องถูก ผูกมัด Android 8.0 ยังมีการปรับปรุงที่สำคัญเหล่านี้สำหรับบริการกล้อง:
- พื้นผิวที่ใช้ร่วมกัน: เปิดใช้งานหลายพื้นผิวที่แชร์
OutputConfiguration
เดียวกัน - System API สำหรับโหมดกล้องแบบกำหนดเอง
-
onCaptureQueueEmpty
ดูส่วนด้านล่างสำหรับข้อมูลเพิ่มเติมเกี่ยวกับคุณลักษณะเหล่านี้
พื้นผิวที่ใช้ร่วมกัน
คุณลักษณะนี้เปิดใช้งานบัฟเฟอร์ชุดเดียวเท่านั้นเพื่อขับเคลื่อนสองเอาต์พุต เช่น การแสดงตัวอย่างและการเข้ารหัสวิดีโอ ซึ่งช่วยลดการใช้พลังงานและหน่วยความจำ เพื่อรองรับคุณสมบัตินี้ ผู้ผลิตอุปกรณ์จำเป็นต้องตรวจสอบให้แน่ใจว่าการใช้งานกล้อง HAL และ gralloc HAL สามารถสร้างบัฟเฟอร์ gralloc ที่ผู้ใช้หลายรายใช้ (เช่น ฮาร์ดแวร์ผู้แต่ง/GPU และตัวเข้ารหัสวิดีโอ) แทนที่จะเป็นผู้บริโภคเพียงรายเดียว บริการกล้องส่งแฟล็กการใช้งานของผู้บริโภคไปที่กล้อง HAL และ gralloc HAL พวกเขาจำเป็นต้องจัดสรรบัฟเฟอร์ประเภทที่เหมาะสม มิฉะนั้น HAL ของกล้องจำเป็นต้องส่งคืนข้อผิดพลาดที่ผู้ใช้ไม่รองรับการรวมกันนี้
ดูเอกสารสำหรับนักพัฒนา enableSurfaceSharing
สำหรับรายละเอียดเพิ่มเติม
System 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
onCaptureQueueEmpty
จุดประสงค์ของ 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 - flush call เพื่อยกเลิกคำขอ/บัฟเฟอร์ในเที่ยวบินทั้งหมดโดยเร็วที่สุด
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_module_t.common.module_api_version
เลขฐานสิบหกที่สำคัญที่สุดสองตัวคือรุ่นหลัก และเลขฐานสิบหกที่มีนัยสำคัญน้อยที่สุดสองตัวคือรุ่นรอง
2.4
เวอร์ชันโมดูลกล้องนี้เพิ่มการเปลี่ยนแปลง API ต่อไปนี้:
- รองรับโหมดไฟฉาย เฟรมเวิร์กสามารถเปิดโหมดไฟฉายสำหรับอุปกรณ์กล้องใดๆ ที่มีชุดแฟลช โดยไม่ต้องเปิดอุปกรณ์กล้อง อุปกรณ์กล้องมีลำดับความสำคัญสูงกว่าในการเข้าถึงชุดแฟลชมากกว่าโมดูลกล้อง การเปิดอุปกรณ์กล้องจะปิดไฟฉายหากเปิดใช้งานผ่านอินเทอร์เฟซโมดูล เมื่อมีความขัดแย้งของทรัพยากร เช่น เรียกใช้
open()
เพื่อเปิดอุปกรณ์กล้อง โมดูล HAL ของกล้องต้องแจ้งเฟรมเวิร์กผ่านการเรียกกลับสถานะโหมดคบเพลิงว่าโหมดคบเพลิงปิดอยู่ - รองรับกล้องภายนอก (เช่น กล้องฮอตปลั๊ก USB) การอัปเดต API ระบุข้อมูลคงที่ของกล้องจะใช้ได้เฉพาะเมื่อเชื่อมต่อกล้องและพร้อมใช้งานสำหรับกล้อง hot-plug ภายนอกเท่านั้น การโทรเพื่อรับข้อมูลคงที่เป็นการโทรที่ไม่ถูกต้องเมื่อสถานะกล้องไม่ใช่
CAMERA_DEVICE_STATUS_PRESENT
เฟรมเวิร์กจะนับเฉพาะการโทรกลับเพื่อเปลี่ยนสถานะของอุปกรณ์เพื่อจัดการรายการกล้องภายนอกที่มีอยู่ - คำแนะนำอนุญาโตตุลาการของกล้อง เพิ่มการรองรับการระบุจำนวนอุปกรณ์กล้องที่สามารถเปิดและใช้งานพร้อมกันได้อย่างชัดเจน ในการระบุชุดค่าผสมของอุปกรณ์ที่ถูกต้อง ควรตั้งค่าฟิลด์
resource_cost
และconflicting_devices
ในโครงสร้างcamera_info
ที่ส่งคืนโดยการโทรget_camera_info
- วิธีการเริ่มต้นโมดูล เรียกโดยบริการกล้องหลังจากโหลดโมดูล 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 ของโมดูลกล้องเริ่มต้น อุปกรณ์กล้องทั้งหมดที่เปิดได้ผ่านโมดูลนี้รองรับเฉพาะรุ่น 1 ของอุปกรณ์กล้อง HAL device_version
และ static_camera_characteristics
ของ camera_info
ไม่ถูกต้อง โมดูลนี้และอุปกรณ์ที่รองรับ android.hardware.Camera
API เท่านั้น