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

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

คำศัพท์

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

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

API กล้อง

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

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

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

  • อินเทอร์เฟซ 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 ที่รองรับ จะพร้อมใช้งานเป็นค่าสถานะฟีเจอร์ต่อไปนี้เพื่อ อนุญาตให้ 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 ขึ้นไปต้องผ่าน CTS ของ Camera API1, CTS ของ Camera API2 และการทดสอบกล้องของ CTS Verifier

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

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

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

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

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

Android 7.0 ย้ายบริการกล้องออกจาก mediaserver เพื่อเพิ่มความปลอดภัยของเฟรมเวิร์กสื่อและกล้อง ตั้งแต่ Android 8.0 เป็นต้นไป Camera HAL ที่ใช้ Binder จะทำงานในกระบวนการที่แยกจากบริการกล้อง ผู้ให้บริการอาจต้องทำการเปลี่ยนแปลงใน 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 (ระบบไม่รองรับ kMetadataBufferTypeCameraSource ใน Android 7.0 อีกต่อไป)

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

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

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

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

  • HAL1 ไม่ได้รับผลกระทบจากการย้าย cameraservice และไม่จำเป็นต้องอัปเดตผู้ให้บริการ
  • 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 หลังจากที่ 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 ให้ยืนยันการ ติดตั้งใช้งานโดยเรียกใช้ CTS ของ Android 7.0 แม้ว่า 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

  • getPhysicalCameraCharacteristics: ข้อมูลกล้องแบบคงที่สำหรับรหัสกล้องจริงที่รองรับอุปกรณ์กล้อง ตรรกะ ดู การรองรับกล้องหลายตัว
  • isStreamCombinationSupported: วิธีนี้รองรับ API สาธารณะ ที่ช่วยให้ไคลเอ็นต์ค้นหาได้ว่าระบบรองรับการกำหนดค่าเซสชันหรือไม่ ดู API เพื่อค้นหาการผสมสตรีม

ICameraDeviceSession

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

การอัปเดตเกี่ยวกับ ICameraDeviceCallback

  • requestStreamBuffers: การเรียกกลับแบบซิงโครนัสที่ HAL ของกล้องเรียกเพื่อขอ บัฟเฟอร์จากเซิร์ฟเวอร์กล้อง ดู requestStreamBuffers
  • returnStreamBuffers: การเรียกกลับแบบซิงโครนัสสำหรับ HAL ของกล้องเพื่อส่งคืนบัฟเฟอร์เอาต์พุตไปยัง เซิร์ฟเวอร์กล้อง ดู returnStreamBuffers

3.4

ระบบจะเพิ่มคีย์ต่อไปนี้ลงในข้อมูลเมตาของกล้องใน Android 10

  • รูปแบบรูปภาพ
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
    • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
  • แท็กข้อมูลเมตาของกล้อง
    • ANDROID_REQUEST_CHARACTERISTIC_KEYS_NEEDING_PERMISSION
    • ANDROID_SCALER_AVAILABLE_RECOMMENDED_STREAM_CONFIGURATIONS
    • ANDROID_SCALER_AVAILABLE_RECOMMENDED_INPUT_OUTPUT_FORMATS_MAP
    • ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION
    • ANDROID_DEPTH_AVAILABLE_RECOMMENDED_DEPTH_STREAM_CONFIGURATIONS
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_MIN_FRAME_DURATIONS
    • ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS
    • ANDROID_HEIC_AVAILABLE_HEIC_MIN_FRAME_DURATIONS
    • ANDROID_HEIC_AVAILABLE_HEIC_STALL_DURATIONS
    • ANDROID_HEIC_INFO_SUPPORTED
    • ANDROID_HEIC_INFO_MAX_JPEG_APP_SEGMENTS_COUNT
  • ความสามารถ
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
  • ค่าสำหรับคีย์ ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • การกำหนดค่าสตรีมความลึกแบบไดนามิกที่พร้อมใช้งาน
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • การกำหนดค่าสตรีม HEIC ที่พร้อมใช้งาน
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

โมดูลกล้อง

เวอร์ชันโมดูลกล้องต่อไปนี้ได้รับการอัปเดตใน Android 10

2.5

  • เพิ่มnotifyDeviceStateChangeวิธีให้อุปกรณ์แจ้ง HAL ของกล้องเมื่อมีการเปลี่ยนแปลงทางกายภาพ เช่น การพับ ซึ่งส่งผลต่อกล้องและ การกำหนดเส้นทาง

2.4

  • อุปกรณ์ที่เปิดตัวด้วย API ระดับ 29 ขึ้นไปต้องรายงาน true สำหรับ isTorchModeSupported

Android 9

การเปิดตัว Android 9 มีการอัปเดตต่อไปนี้ใน 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

Android 8.0

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

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

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

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

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

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 ในเลเยอร์บริการกล้อง
  • ไม่ได้ทดสอบฟีเจอร์ใหม่ๆ เช่น การควบคุมการจับภาพด้วยตนเอง การจับภาพ Bayer RAW การประมวลผลข้อมูล RAW ซ้ำ ฯลฯ

1.0

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

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

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

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

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 เวอร์ชันที่ต่ำกว่า 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 เท่านั้น