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

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

คำศัพท์

หน้านี้ใช้คำต่อไปนี้

API กล้องถ่ายรูป1
เฟรมเวิร์กกล้องระดับแอปในอุปกรณ์ Android 4.4 และต่ำกว่า ผ่านชั้นเรียน android.hardware.Camera
API กล้อง 2
เฟรมเวิร์กกล้องระดับแอปบนอุปกรณ์ Android 5.0 ขึ้นไปที่เผยให้เห็นเนื้อใน ผ่านแพ็กเกจ android.hardware.camera2
HAL ของกล้อง
เลเยอร์โมดูลกล้องที่ผู้ให้บริการ SoC ใช้ สาธารณะระดับแอป จะสร้างขึ้นจาก HAL ของกล้อง
กล้อง HAL3.1
เวอร์ชัน HAL ของอุปกรณ์กล้องที่เปิดตัวพร้อม Android 4.4
กล้อง HAL3.2
เวอร์ชัน HAL ของอุปกรณ์กล้องที่เปิดตัวใน Android 5.0
API1 CTS ของกล้อง
ชุดการทดสอบ CTS ของกล้องที่ทำงานเหนือกล้อง API1
API2 CTS ของกล้อง
ชุดการทดสอบ CTS เพิ่มเติมของกล้องที่ทำงานบน Camera API2
เสียงแหลม
แยกการใช้งานของผู้ให้บริการ (ซอฟต์แวร์เฉพาะอุปกรณ์และระดับล่าง) (ซึ่งเขียนโดยผู้ผลิตซิลิคอน) จากเฟรมเวิร์กระบบปฏิบัติการ Android ผ่าน ให้กับผู้ให้บริการ
แบบ HIDL
ภาษาคำจำกัดความของอินเทอร์เฟซ HAL เปิดตัวด้วย Treble และใช้เพื่อระบุอินเทอร์เฟซระหว่าง HAL กับ ผู้ใช้ของเขา
VTS
เปิดตัวชุดทดสอบสำหรับผู้ให้บริการควบคู่ไปกับ เสียงแหลม

API กล้อง

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

API กล้องถ่ายรูป1

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

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

API กล้อง 2

เฟรมเวิร์ก 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 (แต่ไม่ใช่ทั้งหมด) และต้องใช้ HAL ของกล้อง 3.2 ขึ้นไป
  • FULL: อุปกรณ์เหล่านี้รองรับความสามารถหลักทั้งหมดของ Camera API2 และต้องใช้ 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 ต้องมีการกำหนดเสมอ

ระดับฮาร์ดแวร์ที่รองรับของอุปกรณ์ ตลอดจนกล้องที่เฉพาะเจาะจง ความสามารถของ API2 ที่ API รองรับมีพร้อมแฟล็กฟีเจอร์ต่อไปนี้ อนุญาตให้ Google Play กรองแอปกล้องถ่ายรูป 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

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

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

ข้อกำหนดของ VTS

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

การปิดขอบกรอบกล้อง

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

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

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

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

    กล้องและสื่อของ Android 7.0 สแต็กใน API1 บน HAL3

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

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

    กล้องและสื่อของ Android 7.0 สแต็กใน API1 บน HAL1

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

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

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

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

    กล้อง Android 7.0 และ สแต็กสื่อใน API2 บน HAL3

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

ข้อกำหนดเพิ่มเติม

การเปลี่ยนแปลงด้านสถาปัตยกรรมเพื่อเสริมความแข็งแกร่งให้กับเฟรมเวิร์กสื่อและกล้อง รวมถึงข้อกำหนดเพิ่มเติมของอุปกรณ์ดังนี้

  • ทั่วไป อุปกรณ์ต้องใช้แบนด์วิดท์เพิ่มเติมเนื่องจาก IPC ซึ่งอาจส่งผลต่อกรณีการใช้งานกล้องที่จำกัดเวลา เช่น วิดีโอความเร็วสูง บันทึก ผู้ให้บริการสามารถวัดผลกระทบที่เกิดขึ้นจริงโดยการเรียกใช้ android.hardware.camera2.cts.PerformanceTest และ Google กล้องถ่ายรูป แอปสำหรับการบันทึกวิดีโอความเร็วสูง 120/240 FPS นอกจากนี้ อุปกรณ์จะต้องมี RAM เพิ่มเติมเพียงเล็กน้อยเพื่อสร้างกระบวนการใหม่
  • ส่งข้อมูลเมตาในบัฟเฟอร์วิดีโอ (เฉพาะ HAL1 เท่านั้น) หากเป็น HAL1 จัดเก็บข้อมูลเมตาแทนข้อมูลเฟรม YUV จริงในบัฟเฟอร์วิดีโอ HAL ใช้ kMetadataBufferTypeNativeHandleSource เป็นบัฟเฟอร์ข้อมูลเมตา พิมพ์และส่ง VideoNativeHandleMetadata ในบัฟเฟอร์วิดีโอ (ไม่รองรับ kMetadataBufferTypeCameraSource ใน Android แล้ว 7.0) เฟรมเวิร์กกล้องและสื่อด้วย VideoNativeHandleMetadata สามารถส่งผ่านบัฟเฟอร์วิดีโอระหว่างขั้นตอนต่างๆ โดยการเรียงลำดับและ การดีซีเรียลไลซ์แฮนเดิลดั้งเดิมอย่างถูกต้อง
  • ที่อยู่แฮนเดิลของบัฟเฟอร์ไม่เก็บบัฟเฟอร์เดียวกันเสมอไป (เฉพาะ HAL3 เท่านั้น) สำหรับคำขอจับภาพแต่ละรายการ HAL3 จะได้รับที่อยู่ของบัฟเฟอร์ แฮนเดิล HAL ไม่สามารถใช้ที่อยู่เพื่อระบุบัฟเฟอร์เนื่องจากที่อยู่ อาจจัดเก็บแฮนเดิลอื่นหลังจากที่ HAL ส่งคืนบัฟเฟอร์แล้ว คุณต้องอัปเดต HAL เพื่อใช้แฮนเดิลบัฟเฟอร์เพื่อระบุบัฟเฟอร์ ตัวอย่างเช่น HAL ได้รับ ที่อยู่แฮนเดิล A ของบัฟเฟอร์ A ซึ่งเก็บแฮนเดิล A หลังจาก HAL กลับมา แฮนเดิล A, ที่อยู่แฮนเดิล A ของบัฟเฟอร์ A อาจจัดเก็บแฮนเดิล B ในครั้งถัดไปที่ โดย HAL ได้รับคำตอบ
  • อัปเดตนโยบาย SELinux สำหรับ Cameraserver ถ้า นโยบาย SELinux เฉพาะอุปกรณ์ให้สิทธิ์เซิร์ฟเวอร์สื่อในการเรียกใช้กล้อง คุณต้องอัปเดตนโยบาย SELinux เพื่อให้สิทธิ์ที่เหมาะสมแก่ Cameraserver พ ไม่สนับสนุนให้จำลองนโยบาย SELinux ของเซิร์ฟเวอร์สื่อสำหรับเซิร์ฟเวอร์กล้อง (เนื่องจากโดยทั่วไป Mediaserver และ Cameraserver ต้องการทรัพยากรที่แตกต่างกันใน ) Cameraserver ควรมีเฉพาะสิทธิ์ที่จำเป็นต่อการใช้งานกล้องเท่านั้น ฟังก์ชันและสิทธิ์เกี่ยวกับกล้องที่ไม่จำเป็นใน Mediaserver ควรลบออก
  • การแยกระหว่าง HAL ของกล้องและ Cameraserver แอนดรอยด์ 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 กล้องถ่ายรูป

HAL ของกล้อง

เวอร์ชัน HAL ของกล้องต่อไปนี้ได้รับการอัปเดตใน Android แล้ว 10.

3.5

ICameraDevice

ICameraDeviceSession

  • isReconfigurationNeeded: วิธีที่บอกเฟรมเวิร์กของกล้องว่าสตรีมสมบูรณ์หรือไม่ ต้องมีการกําหนดค่าใหม่สําหรับค่าพารามิเตอร์เซสชันใหม่ที่เป็นไปได้ ช่วงเวลานี้ ช่วยหลีกเลี่ยงความล่าช้าในการกำหนดค่ากล้องใหม่โดยไม่จำเป็น โปรดดู การค้นหาเกี่ยวกับการกำหนดค่าเซสชันใหม่
  • ฮัล Buffer Management API: API เหล่านี้ช่วยให้ HAL ของกล้องขอได้ จะบัฟเฟอร์จากเฟรมเวิร์กของกล้องถ่ายรูปเมื่อจำเป็นเท่านั้น แทนที่จะต้องเชื่อมต่อกัน คำขอจับภาพที่มีบัฟเฟอร์ที่เกี่ยวข้องตลอดไปป์ไลน์ของกล้อง ซึ่งอาจช่วยลดการใช้หน่วยความจำได้อย่างมาก
    • signalStreamFlush: ส่งสัญญาณไปยัง HAL ที่กล้อง บริการกำลังจะดำเนินการ configureStreams_3_5 และ HAL จะต้องส่งคืนบัฟเฟอร์ทั้งหมดของสตรีมที่กำหนด
    • configureStreams_3_5: คล้ายกับ ICameraDevice3.4.configureStreams แต่อยู่ใน ยิ่งไปกว่านั้น ตัวนับ streamConfigCounter ยังใช้กับ ตรวจหาเงื่อนไขการแข่งขันระหว่าง configureStreams_3_5 และ signalStreamFlush สาย

การอัปเดตสำหรับ ICameraDeviceCallback:

  • requestStreamBuffers: Callback แบบซิงโครนัสที่ HAL ของกล้องเรียกใช้เพื่อขอเซิร์ฟเวอร์กล้อง บัฟเฟอร์ โปรดดู requestStreamBuffers
  • returnStreamBuffers: Callback แบบซิงโครนัสสำหรับ 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 มีการอัปเดตต่อไปนี้สำหรับ API ของกล้อง2 และ อินเทอร์เฟซ HAL

API กล้องถ่ายรูป

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

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

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

แพลตฟอร์มที่แชร์

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

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

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

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

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

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

ชื่อเมธอดคือ android.hardware.camera2.CameraDevice#createCustomCaptureSession โปรดดูหัวข้อต่อไปนี้ frameworks/base/core/java/android/hardware/camera2/CameraDevice

onCaptureQueue ว่างเปล่า

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

อินเทอร์เฟซ 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 ความสามารถในการเพิ่มความสามารถในการทำงานเล็กน้อย

  • OPAQUE และ YUV กำลังประมวลผลการอัปเดต API ใหม่
  • การรองรับระดับพื้นฐานสำหรับบัฟเฟอร์เอาต์พุตของความลึก
  • การเพิ่มช่อง 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 ส่งการแจ้งการใช้งานของผู้บริโภคไปยัง 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

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

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

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

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

2.4

โมดูลกล้องเวอร์ชันนี้เพิ่มการเปลี่ยนแปลง API ต่อไปนี้

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

2.3

โมดูลกล้องเวอร์ชันนี้เพิ่มการรองรับอุปกรณ์ระดับ HAL ของกล้องแบบเดิมแบบเปิด เฟรมเวิร์กสามารถใช้เฟรมเวิร์กเพื่อเปิดอุปกรณ์กล้องเป็นเวอร์ชัน HAL ที่ต่ำกว่าของอุปกรณ์ อุปกรณ์ HAL หากอุปกรณ์เดียวกันสามารถรองรับ API อุปกรณ์หลายเวอร์ชัน การประชุมแบบเปิดของโมดูลฮาร์ดแวร์มาตรฐาน (common.methods->open) ดำเนินต่อไป เพื่อเปิดอุปกรณ์กล้องที่มีเวอร์ชันล่าสุดที่รองรับ ซึ่งได้แก่ ซึ่งเป็นเวอร์ชันที่แสดงใน camera_info_t.device_version ด้วย

2.2

โมดูลกล้องเวอร์ชันนี้เพิ่มการรองรับแท็กผู้ให้บริการจากโมดูล และ เลิกใช้งาน vendor_tag_query_ops เดิมที่ก่อนหน้านี้ใช้เพียง เข้าถึงได้เมื่อเปิดอุปกรณ์ไว้

2.1

โมดูลกล้องเวอร์ชันนี้เพิ่มการรองรับ Callback แบบไม่พร้อมกันไปยังฟังก์ชัน จากโมดูล HAL ของกล้อง ซึ่งใช้เพื่อแจ้งเฟรมเวิร์ก เกี่ยวกับการเปลี่ยนแปลงสถานะของโมดูลกล้อง โมดูลที่ระบุฟิลด์ เมธอด set_callbacks() ต้องรายงานหมายเลขเวอร์ชันนี้เป็นอย่างน้อย

2.0

โมดูลกล้องที่รายงานหมายเลขเวอร์ชันนี้ใช้เวอร์ชัน 2 ของอินเทอร์เฟซ HAL ของโมดูลกล้อง อุปกรณ์กล้องที่เปิดด้วยได้ โมดูลอาจสนับสนุนอุปกรณ์กล้องรุ่น 1.0 หรือ 2.0 อินเทอร์เฟซ HAL ช่อง 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 ไม่ถูกต้อง เฉพาะ โมดูลนี้และโมดูลรองรับ API ของ android.hardware.Camera ได้ อุปกรณ์