Hỗ trợ phiên bản máy ảnh

Trang này trình bày chi tiết sự khác biệt về phiên bản trong các bài kiểm thử Camera HAL, API và Bộ kiểm tra tính tương thích (CTS) liên kết. Khoá học này cũng đề cập đến một số thay đổi về cấu trúc được thực hiện để tăng cường và bảo mật khung camera trong Android 7.0, việc chuyển sang Treble trong Android 8.0 và những nội dung cập nhật mà nhà cung cấp phải thực hiện để hỗ trợ những thay đổi này trong quá trình triển khai camera.

Thuật ngữ

Các thuật ngữ sau đây được dùng trên trang này:

Camera API1
Khung camera cấp ứng dụng trên các thiết bị chạy Android 4.4 trở xuống, được hiển thị thông qua lớp android.hardware.Camera.
Camera API2
Khung camera cấp ứng dụng trên các thiết bị Android 5.0 trở lên, được hiển thị thông qua gói android.hardware.camera2.
HAL (Lớp trừu tượng phần cứng) của camera
Lớp mô-đun camera do nhà cung cấp SoC triển khai. Các khung công khai ở cấp ứng dụng được xây dựng dựa trên HAL camera.
Camera HAL3.1
Phiên bản HAL của thiết bị máy ảnh được phát hành cùng với Android 4.4.
Camera HAL3.2
Phiên bản HAL của thiết bị camera được phát hành cùng với Android 5.0.
Camera API1 CTS
Tập hợp các kiểm thử CTS của camera chạy trên Camera API1.
Camera API2 CTS
Một nhóm kiểm thử CTS bổ sung cho camera chạy trên API Camera2.
Âm bổng
Tách quá trình triển khai của nhà cung cấp (phần mềm cấp thấp dành riêng cho thiết bị do nhà sản xuất silicon viết) khỏi khung hệ điều hành Android thông qua một giao diện nhà cung cấp mới.
HIDL
Ngôn ngữ định nghĩa giao diện HAL được giới thiệu cùng với Treble và dùng để chỉ định giao diện giữa HAL và người dùng của HAL.
VTS
Bộ thử nghiệm của nhà cung cấp được giới thiệu cùng với Treble.

Camera API

Android có các API máy ảnh sau.

Camera API1

Android 5.0 đã ngừng sử dụng Camera API1 và API này sẽ tiếp tục bị loại bỏ dần khi quá trình phát triển nền tảng mới tập trung vào Camera API2. Tuy nhiên, giai đoạn ngừng hoạt động sẽ kéo dài và các bản phát hành Android sẽ tiếp tục hỗ trợ các ứng dụng Camera API1 trong một thời gian. Cụ thể, chúng tôi vẫn tiếp tục hỗ trợ:

  • Giao diện Camera API1 cho các ứng dụng. Các ứng dụng máy ảnh được xây dựng dựa trên Camera API1 sẽ hoạt động như trên các thiết bị chạy phiên bản phát hành Android thấp hơn.
  • Các phiên bản HAL của máy ảnh. Bao gồm cả việc hỗ trợ Camera HAL1.0.

Camera API2

Khung Camera API2 cung cấp quyền kiểm soát camera ở cấp độ thấp cho ứng dụng, bao gồm cả các luồng truyền phát/phát trực tiếp hiệu quả không sao chép và các chế độ kiểm soát theo từng khung hình về độ phơi sáng, độ khuếch đại, độ khuếch đại cân bằng trắng, chuyển đổi màu, khử nhiễu, làm sắc nét và nhiều chế độ khác. Để biết thông tin chi tiết, hãy xem Tổng quan về video Google I/O.

Android 5.0 trở lên có Camera API2; tuy nhiên, các thiết bị chạy Android 5.0 trở lên có thể không hỗ trợ tất cả các tính năng của Camera API2. Thuộc tính android.info.supportedHardwareLevel mà các ứng dụng có thể truy vấn thông qua các giao diện Camera API2 sẽ báo cáo một trong các cấp độ hỗ trợ sau:

  • LEGACY: Các thiết bị này cung cấp các chức năng cho ứng dụng thông qua các giao diện Camera API2. Đây là những chức năng gần giống với những chức năng được cung cấp cho ứng dụng thông qua các giao diện Camera API1. Về mặt khái niệm, mã khung cũ sẽ chuyển các lệnh gọi Camera API2 thành lệnh gọi Camera API1; các thiết bị cũ không hỗ trợ các tính năng Camera API2 như chế độ kiểm soát theo từng khung hình.
  • LIMITED: Những thiết bị này hỗ trợ một số (nhưng không phải tất cả) chức năng của Camera API2 và phải sử dụng Camera HAL 3.2 trở lên.
  • FULL: Các thiết bị này hỗ trợ tất cả các chức năng chính của Camera API2 và phải sử dụng Camera HAL 3.2 trở lên và Android 5.0 trở lên.
  • LEVEL_3: Các thiết bị này hỗ trợ quy trình xử lý lại YUV và tính năng chụp ảnh RAW, cùng với các cấu hình luồng đầu ra bổ sung.
  • EXTERNAL: Những thiết bị này tương tự như thiết bị LIMITED, nhưng có một số trường hợp ngoại lệ; ví dụ: một số thông tin về cảm biến hoặc ống kính có thể không được báo cáo hoặc có tốc độ khung hình kém ổn định hơn. Cấp độ này được dùng cho các camera bên ngoài, chẳng hạn như webcam USB.

Các chức năng riêng lẻ được cung cấp thông qua thuộc tính android.request.availableCapabilities trong các giao diện Camera API2. Các thiết bị FULL yêu cầu có các chức năng MANUAL_SENSOR và MANUAL_POST_PROCESSING, cùng nhiều chức năng khác. Bạn không bắt buộc phải có khả năng RAW, ngay cả đối với các thiết bị FULL. Các thiết bị LIMITED có thể quảng cáo bất kỳ nhóm nhỏ nào trong số các chức năng này, kể cả không có chức năng nào. Tuy nhiên, bạn phải luôn xác định khả năng BACKWARD_COMPATIBLE.

Cấp độ phần cứng được hỗ trợ của thiết bị, cũng như các chức năng cụ thể của Camera API2 mà thiết bị hỗ trợ, có sẵn dưới dạng các cờ tính năng sau đây để cho phép Google Play lọc các ứng dụng camera 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

Yêu cầu về CTS

Các thiết bị chạy Android 5.0 trở lên phải vượt qua Camera API1 CTS, Camera API2 CTS và các bài kiểm thử camera của CTS Verifier.

Những thiết bị không có chế độ triển khai Camera HAL3.2 và không hỗ trợ đầy đủ các giao diện Camera API2 vẫn phải vượt qua các bài kiểm thử CTS Camera API2. Tuy nhiên, thiết bị này chạy ở chế độ Camera API2 LEGACY (trong đó các lệnh gọi Camera API2 được ánh xạ theo khái niệm đến các lệnh gọi Camera API1) nên mọi kiểm thử CTS Camera API2 liên quan đến các tính năng hoặc khả năng ngoài Camera API1 đều tự động bị bỏ qua.

Trên các thiết bị cũ, các kiểm thử CTS Camera API2 được chạy sẽ sử dụng các giao diện và chức năng Camera API1 công khai hiện có mà không có yêu cầu mới. Các lỗi được hiển thị (và gây ra lỗi CTS Camera API2) là những lỗi đã có trong Camera HAL hiện tại của thiết bị. Do đó, các ứng dụng Camera API1 hiện tại sẽ phát hiện được những lỗi này. Chúng tôi không mong đợi nhiều lỗi thuộc loại này (tuy nhiên, mọi lỗi như vậy phải được khắc phục để vượt qua các bài kiểm thử CTS Camera API2).

Yêu cầu về VTS

Các thiết bị chạy Android 8.0 trở lên có các chế độ triển khai HAL được liên kết phải vượt qua các kiểm thử VTS của Camera.

Tăng cường khung camera

Để tăng cường bảo mật cho khung camera và nội dung nghe nhìn, Android 7.0 sẽ di chuyển dịch vụ camera ra khỏi mediaserver. Kể từ Android 8.0, mỗi HAL Camera được liên kết sẽ chạy trong một quy trình tách biệt với dịch vụ máy ảnh. Nhà cung cấp có thể cần thực hiện các thay đổi trong HAL camera tuỳ thuộc vào API và phiên bản HAL đang sử dụng. Các phần sau đây trình bày chi tiết những thay đổi về cấu trúc trong AP1 và AP2 cho HAL1 và HAL3, cũng như các yêu cầu chung.

Các thay đổi về cấu trúc đối với API1

Tính năng quay video API1 có thể giả định rằng camera và bộ mã hoá video nằm trong cùng một quy trình. Khi sử dụng API1 trên:

  • HAL3, trong đó dịch vụ camera dùng BufferQueue để truyền các vùng đệm giữa các quy trình, không cần bản cập nhật của nhà cung cấp.

    Ngăn xếp camera và nội dung nghe nhìn Android 7.0 trong API1 trên HAL3

    Hình 1. Ngăn xếp camera và nội dung nghe nhìn Android 7.0 trong API1 trên HAL3

  • HAL1 hỗ trợ truyền siêu dữ liệu trong các vùng đệm video, nhà cung cấp phải cập nhật HAL để sử dụng kMetadataBufferTypeNativeHandleSource. (kMetadataBufferTypeCameraSource không còn được hỗ trợ trong Android 7.0.)

    Ngăn xếp camera và nội dung nghe nhìn Android 7.0 trong API1 trên HAL1

    Hình 2. Ngăn xếp camera và nội dung nghe nhìn Android 7.0 trong API1 trên HAL1

Các thay đổi về cấu trúc đối với API2

Đối với API2 trên HAL1 hoặc HAL3, BufferQueue sẽ truyền các vùng đệm để những đường dẫn đó tiếp tục hoạt động. Cấu trúc Android 7.0 cho API2 trên:

  • HAL1 không bị ảnh hưởng bởi việc di chuyển cameraservice và không cần cập nhật nhà cung cấp.
  • HAL3 bị ảnh hưởng, nhưng không cần bản cập nhật của nhà cung cấp:

    Ngăn xếp camera và nội dung nghe nhìn Android 7.0 trong API2 trên HAL3

    Hình 3. Ngăn xếp camera và nội dung nghe nhìn Android 7.0 trong API2 trên HAL3

Yêu cầu khác

Những thay đổi về cấu trúc được thực hiện để tăng cường bảo mật cho khung nội dung nghe nhìn và camera bao gồm các yêu cầu bổ sung sau đây đối với thiết bị.

  • Quy định chung. Các thiết bị cần thêm băng thông do IPC, điều này có thể ảnh hưởng đến các trường hợp sử dụng camera nhạy cảm về thời gian, chẳng hạn như quay video tốc độ cao. Nhà cung cấp có thể đo lường tác động thực tế bằng cách chạy android.hardware.camera2.cts.PerformanceTest và ứng dụng Google Camera để quay video tốc độ cao ở tốc độ 120/240 khung hình/giây. Các thiết bị cũng cần thêm một lượng nhỏ RAM để tạo quy trình mới.
  • Truyền siêu dữ liệu trong vùng đệm video (chỉ HAL1). Nếu HAL1 lưu trữ siêu dữ liệu thay vì dữ liệu khung YUV thực trong các vùng đệm video, thì HAL phải sử dụng kMetadataBufferTypeNativeHandleSource làm loại vùng đệm siêu dữ liệu và truyền VideoNativeHandleMetadata trong các vùng đệm video. (kMetadataBufferTypeCameraSource không còn được hỗ trợ trên Android 7.0.) Với VideoNativeHandleMetadata, các khung camera và nội dung nghe nhìn có thể truyền các vùng đệm video giữa các quy trình bằng cách tuần tự hoá và giải tuần tự hoá các trình xử lý gốc một cách thích hợp.
  • Địa chỉ của bộ đệm không phải lúc nào cũng lưu trữ cùng một bộ đệm (Chỉ HAL3). Đối với mỗi yêu cầu chụp, HAL3 sẽ nhận được địa chỉ của các mã nhận dạng vùng đệm. HAL không thể dùng các địa chỉ này để xác định bộ đệm vì các địa chỉ có thể lưu trữ một bộ đệm khác sau khi HAL trả về bộ đệm. Bạn phải cập nhật HAL để sử dụng các mã nhận dạng vùng đệm nhằm xác định vùng đệm. Ví dụ: HAL nhận được địa chỉ A của một vùng đệm, trong đó lưu trữ vùng đệm A. Sau khi HAL trả về A xử lý bộ đệm, địa chỉ A xử lý bộ đệm có thể lưu trữ B xử lý bộ đệm vào lần tiếp theo HAL nhận được.
  • Cập nhật chính sách SELinux cho cameraserver. Nếu các chính sách SELinux dành riêng cho thiết bị cấp quyền cho mediaserver chạy camera, thì bạn phải cập nhật các chính sách SELinux để cấp cho cameraserver các quyền thích hợp. Bạn không nên sao chép các chính sách SELinux của mediaserver cho cameraserver (vì mediaserver và cameraserver thường yêu cầu các tài nguyên khác nhau trong hệ thống). Cameraserver chỉ nên có những quyền cần thiết để thực hiện các chức năng của camera và mọi quyền không cần thiết liên quan đến camera trong mediaserver đều phải bị xoá.
  • Phân tách giữa Camera HAL và cameraserver. Ngoài ra, Android 8.0 trở lên sẽ tách Camera HAL được liên kết trong một quy trình khác với cameraserver. IPC đi qua các giao diện do HIDL xác định.

Xác nhận kết quả

Đối với tất cả các thiết bị có camera và chạy Android 7.0, hãy xác minh việc triển khai bằng cách chạy Android 7.0 CTS. Mặc dù Android 7.0 không có các chương trình kiểm thử CTS mới để xác minh các thay đổi đối với dịch vụ máy ảnh, nhưng các chương trình kiểm thử CTS hiện có sẽ không thành công nếu bạn chưa thực hiện các bản cập nhật nêu trên.

Đối với tất cả các thiết bị có camera và chạy Android 8.0 trở lên, hãy xác minh việc triển khai của nhà cung cấp bằng cách chạy VTS.

Nhật ký phiên bản HAL của camera

Để biết danh sách các kiểm thử có sẵn để đánh giá Android Camera HAL, hãy xem Danh sách kiểm tra kiểm thử Camera HAL.

Android 10

Android 10 có các bản cập nhật sau.

Camera API

HAL (Lớp trừu tượng phần cứng) của camera

Các phiên bản HAL camera sau đây sẽ được cập nhật trong Android 10.

3.5

ICameraDevice

  • getPhysicalCameraCharacteristics: Thông tin camera tĩnh cho một mã nhận dạng camera thực hỗ trợ thiết bị camera logic. Hãy xem phần Hỗ trợ nhiều camera.
  • isStreamCombinationSupported: Phương thức này hỗ trợ một API công khai giúp các ứng dụng khách truy vấn xem cấu hình phiên có được hỗ trợ hay không. Xem API để truy vấn các tổ hợp luồng.

ICameraDeviceSession

  • isReconfigurationNeeded: Phương thức cho biết khung camera có cần định cấu hình lại luồng hoàn chỉnh cho các giá trị tham số phiên mới có thể có hay không. Điều này giúp tránh sự chậm trễ không cần thiết khi định cấu hình lại camera. Xem Truy vấn định cấu hình lại phiên.
  • API quản lý vùng đệm HAL: Các API này cho phép HAL camera chỉ yêu cầu vùng đệm từ khung camera khi cần thay vì ghép từng yêu cầu chụp với các vùng đệm được liên kết trong suốt quy trình camera, dẫn đến việc tiết kiệm đáng kể bộ nhớ.
    • signalStreamFlush: Báo hiệu cho HAL rằng dịch vụ camera sắp thực hiện configureStreams_3_5 và HAL phải trả về tất cả các vùng đệm của các luồng được chỉ định.
    • configureStreams_3_5: Tương tự như ICameraDevice3.4.configureStreams, nhưng ngoài ra, bộ đếm streamConfigCounter được cung cấp để kiểm tra điều kiện xung đột giữa các lệnh gọi configureStreams_3_5 và signalStreamFlush.

Nội dung cập nhật đối với ICameraDeviceCallback:

  • requestStreamBuffers: Lệnh gọi lại đồng bộ mà HAL camera gọi để yêu cầu máy chủ camera cung cấp các vùng đệm. Hãy xem phần requestStreamBuffers.
  • returnStreamBuffers: Lệnh gọi lại đồng bộ cho HAL camera để trả các vùng đệm đầu ra về máy chủ camera. Hãy xem phần returnStreamBuffers.

3.4

Các khoá sau đây được thêm vào siêu dữ liệu của camera trong Android 10.

  • Định dạng hình ảnh
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
    • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
  • Thẻ siêu dữ liệu của camera
    • 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
  • Khả năng
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
  • Giá trị cho khoá ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • Các cấu hình luồng chiều sâu động hiện có
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • Các cấu hình luồng HEIC hiện có
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Mô-đun camera

Các phiên bản mô-đun camera sau đây sẽ được cập nhật trong Android 10.

2.5

  • Thêm phương thức notifyDeviceStateChange để các thiết bị thông báo cho HAL camera khi các thay đổi về mặt vật lý (chẳng hạn như gập) ảnh hưởng đến camera và định tuyến.

2.4

  • Các thiết bị khởi chạy bằng API cấp 29 trở lên PHẢI báo cáo true cho isTorchModeSupported.

Android 9

Bản phát hành Android 9 giới thiệu các bản cập nhật sau đây cho camera API2 và giao diện HAL.

Camera API

  • Giới thiệu API nhiều camera để hỗ trợ tốt hơn các thiết bị có nhiều camera hướng về cùng một hướng, cho phép các tính năng như hiệu ứng bokeh và thu phóng liền mạch. Điều này cho phép các ứng dụng xem nhiều camera trên một thiết bị dưới dạng một đơn vị logic (camera logic). Bạn cũng có thể gửi yêu cầu chụp đến từng thiết bị camera riêng lẻ nằm trong một camera logic. Hãy xem phần Hỗ trợ nhiều camera.
  • Giới thiệu các tham số phiên. Tham số phiên là một tập hợp con của các tham số chụp có sẵn. Các tham số này có thể gây ra tình trạng chậm trễ nghiêm trọng trong quá trình xử lý khi được sửa đổi. Bạn có thể giảm thiểu những chi phí này nếu các ứng dụng truyền giá trị ban đầu trong quá trình khởi chạy phiên chụp. Xem Tham số phiên.
  • Thêm các khoá dữ liệu chống rung quang học (OIS) để chống rung và tạo hiệu ứng ở cấp ứng dụng. Hãy xem phần STATISTICS_OIS_SAMPLES.
  • Thêm tính năng hỗ trợ đèn flash ngoài. Hãy xem phần CONTROL_AE_MODE_ON_EXTERNAL_FLASH.
  • Thêm một ý định theo dõi chuyển động trong CAPTURE_INTENT. Hãy xem phần CONTROL_CAPTURE_INTENT_MOTION_TRACKING.
  • Không dùng LENS_RADIAL_DISTORTION nữa mà thay bằng LENS_DISTORTION.
  • Thêm các chế độ chỉnh sửa biến dạng trong CaptureRequest. Hãy xem phần DISTORTION_CORRECTION_MODE.
  • Thêm tính năng hỗ trợ cho camera USB/UVC bên ngoài trên các thiết bị được hỗ trợ. Hãy xem phần INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

HAL (Lớp trừu tượng phần cứng) của camera

3.4

Nội dung cập nhật đối với ICameraDeviceSession

Nội dung cập nhật đối với ICameraDeviceCallback

3.3

Các khoá sau đây được thêm vào siêu dữ liệu của camera trong Android 9.

  • Khả năng
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • Thẻ siêu dữ liệu của máy ảnh
    • 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

Bản phát hành Android 8.0 giới thiệu Treble. Với Treble, các quy trình triển khai HAL camera của nhà cung cấp phải được liên kết. Android 8.0 cũng có những điểm cải tiến chính sau đây đối với dịch vụ Camera:

  • Bề mặt dùng chung: Cho phép nhiều bề mặt chia sẻ cùng một OutputConfiguration
  • API hệ thống cho các chế độ máy ảnh tuỳ chỉnh
  • onCaptureQueueEmpty

Hãy xem các phần bên dưới để biết thêm thông tin về những tính năng này.

Bề mặt dùng chung

Tính năng này chỉ cho phép một nhóm bộ đệm điều khiển 2 đầu ra, chẳng hạn như bản xem trước và mã hoá video, giúp giảm mức tiêu thụ điện năng và bộ nhớ. Để hỗ trợ tính năng này, các nhà sản xuất thiết bị cần đảm bảo rằng việc triển khai HAL máy ảnh và HAL gralloc có thể tạo các vùng đệm gralloc được nhiều người dùng khác nhau sử dụng (chẳng hạn như trình kết hợp phần cứng/GPU và bộ mã hoá video), thay vì chỉ một người dùng. Dịch vụ camera sẽ truyền các cờ sử dụng của người dùng đến HAL camera và HAL gralloc; các cờ này cần phân bổ đúng loại vùng đệm hoặc HAL camera cần trả về lỗi cho biết rằng tổ hợp người dùng này không được hỗ trợ.

Hãy xem enableSurfaceSharingtài liệu dành cho nhà phát triển để biết thêm thông tin chi tiết.

API hệ thống cho các chế độ máy ảnh tuỳ chỉnh

API máy ảnh công khai xác định 2 chế độ hoạt động: ghi hình tốc độ cao bình thường và có giới hạn. Chúng có ngữ nghĩa khá khác nhau; ví dụ: chế độ tốc độ cao chỉ giới hạn ở tối đa 2 đầu ra cụ thể cùng một lúc. Nhiều OEM đã bày tỏ sự quan tâm đến việc xác định các chế độ tuỳ chỉnh khác cho các chức năng dành riêng cho phần cứng. Về cơ bản, chế độ này chỉ là một số nguyên được truyền đến configure_streams. Xem: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams.

Tính năng này bao gồm một lệnh gọi API hệ thống mà các ứng dụng camera của OEM có thể dùng để bật một chế độ tuỳ chỉnh. Các chế độ này phải bắt đầu ở giá trị nguyên 0x8000 để tránh xung đột với các chế độ trong tương lai được thêm vào API công khai.

Để hỗ trợ tính năng này, các OEM chỉ cần thêm chế độ mới vào HAL của họ, được kích hoạt bằng số nguyên này truyền đến HAL trên configure_streams, sau đó để ứng dụng máy ảnh tuỳ chỉnh của họ sử dụng API hệ thống.

Tên phương thức là android.hardware.camera2.CameraDevice#createCustomCaptureSession. Xem: frameworks/base/core/java/android/hardware/camera2/CameraDevice.

onCaptureQueueEmpty

Mục đích của API này là giảm độ trễ của các thay đổi về chế độ kiểm soát (chẳng hạn như thu phóng) bằng cách giữ cho hàng đợi yêu cầu trống nhất có thể. onCaptureQueueEmptykhông yêu cầu bất kỳ hoạt động nào của HAL; đây hoàn toàn là một tiện ích bổ sung phía khung. Những ứng dụng muốn tận dụng tính năng này cần thêm một trình nghe vào lệnh gọi lại đó và phản hồi một cách thích hợp. Thông thường, bạn có thể làm việc đó bằng cách gửi một yêu cầu chụp khác đến thiết bị camera.

Giao diện HIDL của camera

Giao diện Camera HIDL là một bản đại tu hoàn chỉnh của giao diện Camera HAL, sử dụng các API ổn định do HIDL xác định. Tất cả các tính năng và chức năng của camera được giới thiệu trong các phiên bản cũ gần đây nhất 3.4 và 2.4 (đối với mô-đun camera) cũng là một phần của các định nghĩa HIDL.

3.4

Một số điểm bổ sung nhỏ cho siêu dữ liệu được hỗ trợ và các thay đổi đối với tính năng hỗ trợ data_space:

  • Thêm siêu dữ liệu tĩnh ANDROID_SENSOR_OPAQUE_RAW_SIZE dưới dạng bắt buộc nếu định dạng RAW_OPAQUE được hỗ trợ.
  • Thêm siêu dữ liệu tĩnh ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE làm thông tin bắt buộc nếu có định dạng RAW nào được hỗ trợ.
  • Chuyển trường camera3_stream_t data_space sang một định nghĩa linh hoạt hơn bằng cách sử dụng định nghĩa phiên bản 0 của mã hoá không gian dữ liệu.
  • Các thông tin bổ sung về siêu dữ liệu chung mà bạn có thể dùng cho HAL phiên bản 3.2 trở lên:
    • 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

Bản sửa đổi nhỏ của HAL có khả năng mở rộng:

  • Nội dung cập nhật về API xử lý lại OPAQUE và YUV.
  • Hỗ trợ cơ bản cho các vùng đệm đầu ra về độ sâu.
  • Thêm trường data_space vào camera3_stream_t.
  • Thêm trường xoay vào camera3_stream_t.
  • Bổ sung chế độ thao tác cấu hình luồng camera3 vào camera3_stream_configuration_t.

3.2

Bản sửa đổi nhỏ của HAL có khả năng mở rộng:

  • Ngừng sử dụng get_metadata_vendor_tag_ops. Thay vào đó, hãy sử dụng get_vendor_tag_ops trong camera_common.h.
  • Ngừng sử dụng register_stream_buffers. Tất cả các vùng đệm gralloc do khung cung cấp cho HAL trong process_capture_request có thể mới bất cứ lúc nào.
  • Thêm tính năng hỗ trợ kết quả một phần. process_capture_result có thể được gọi nhiều lần với một tập hợp con của các kết quả có sẵn trước khi có kết quả đầy đủ.
  • Thêm mẫu thủ công vào camera3_request_template. Các ứng dụng có thể dùng mẫu này để kiểm soát trực tiếp các chế độ cài đặt chụp.
  • Điều chỉnh thông số kỹ thuật của luồng đầu vào và luồng hai chiều.
  • Thay đổi đường dẫn trả về của vùng đệm đầu vào. Vùng đệm được trả về trong process_capture_result thay vì process_capture_request.

3.1

Bản sửa đổi nhỏ của HAL có khả năng mở rộng:

  • configure_streams truyền cờ sử dụng của người tiêu dùng đến HAL.
  • lệnh gọi flush để loại bỏ tất cả các yêu cầu/vùng đệm đang diễn ra nhanh nhất có thể.

3

Bản sửa đổi đầu tiên của HAL có khả năng mở rộng:

  • Thay đổi phiên bản chính vì ABI hoàn toàn khác. Không có thay đổi nào đối với các chức năng phần cứng bắt buộc hoặc mô hình hoạt động so với phiên bản 2.0.
  • Làm lại yêu cầu đầu vào và giao diện hàng đợi luồng: Khung gọi vào HAL bằng yêu cầu tiếp theo và các vùng đệm luồng đã được huỷ xếp hàng. Hỗ trợ khung đồng bộ hoá, cần thiết cho việc triển khai hiệu quả.
  • Di chuyển các điều kiện kích hoạt vào yêu cầu, hầu hết các thông báo vào kết quả.
  • Hợp nhất tất cả các lệnh gọi lại vào khung thành một cấu trúc và tất cả các phương thức thiết lập thành một lệnh gọi initialize() duy nhất.
  • Đã chuyển cấu hình luồng thành một lệnh gọi duy nhất để đơn giản hoá việc quản lý luồng. Luồng hai chiều thay thế cấu trúc STREAM_FROM_STREAM.
  • Ngữ nghĩa của chế độ bị hạn chế đối với các thiết bị phần cứng cũ/có giới hạn.

2

Bản phát hành đầu tiên của HAL có khả năng mở rộng (Android 4.2) [camera2.h]:

  • Đủ để triển khai API android.hardware.Camera hiện có.
  • Cho phép hàng đợi ZSL trong lớp dịch vụ camera.
  • Không được kiểm thử cho bất kỳ tính năng mới nào, chẳng hạn như chế độ điều khiển chụp thủ công, chế độ chụp RAW Bayer, xử lý lại dữ liệu RAW, v.v.

1.0

HAL camera Android ban đầu (Android 4.0) [camera.h]:

  • Chuyển đổi từ lớp trừu tượng CameraHardwareInterface C++.
  • Hỗ trợ API android.hardware.Camera.

Nhật ký phiên bản của mô-đun camera

Phần này chứa thông tin về việc lập phiên bản mô-đun cho mô-đun phần cứng Camera, dựa trên camera_module_t.common.module_api_version. Hai chữ số thập lục phân có nghĩa nhất đại diện cho phiên bản chính và hai chữ số có nghĩa ít nhất đại diện cho phiên bản phụ.

2.4

Phiên bản mô-đun camera này bổ sung các thay đổi sau đây về API:

  1. Hỗ trợ chế độ đèn pin. Khung này có thể bật chế độ đèn pin cho mọi thiết bị camera có bộ phận đèn flash mà không cần mở thiết bị camera. Thiết bị camera có mức độ ưu tiên cao hơn khi truy cập vào bộ phận đèn flash so với mô-đun camera; việc mở một thiết bị camera sẽ tắt đèn pin nếu đèn pin đã được bật thông qua giao diện mô-đun. Khi có bất kỳ xung đột nào về tài nguyên, chẳng hạn như open() được gọi để mở một thiết bị camera, mô-đun HAL camera phải thông báo cho khung thông qua lệnh gọi lại trạng thái chế độ đèn pin rằng chế độ đèn pin đã tắt.
  2. Hỗ trợ camera bên ngoài (ví dụ: camera USB cắm nóng). Các bản cập nhật API chỉ định rằng thông tin tĩnh về camera chỉ có khi camera được kết nối và sẵn sàng sử dụng cho các camera cắm nóng bên ngoài. Các lệnh gọi để lấy thông tin tĩnh là lệnh gọi không hợp lệ khi trạng thái máy ảnh không phải là CAMERA_DEVICE_STATUS_PRESENT. Khung này chỉ dựa vào các lệnh gọi lại thay đổi trạng thái thiết bị để quản lý danh sách camera ngoài hiện có.
  3. Gợi ý phân xử bằng trọng tài cho camera. Thêm tính năng hỗ trợ để chỉ rõ số lượng thiết bị camera có thể được mở và sử dụng đồng thời. Để chỉ định các tổ hợp thiết bị hợp lệ, bạn phải luôn đặt các trường resource_cost và conflicting_devices trong cấu trúc camera_info do lệnh gọi get_camera_info trả về.
  4. Phương thức khởi chạy mô-đun. Được dịch vụ camera gọi sau khi mô-đun HAL được tải để cho phép khởi chạy HAL một lần. Phương thức này được gọi trước khi bất kỳ phương thức mô-đun nào khác được gọi.

2.3

Phiên bản mô-đun camera này bổ sung khả năng hỗ trợ thiết bị HAL camera cũ mở. Khung này có thể dùng để mở thiết bị camera dưới dạng thiết bị HAL có phiên bản HAL thấp hơn nếu cùng một thiết bị có thể hỗ trợ nhiều phiên bản API thiết bị. Lệnh gọi mở mô-đun phần cứng tiêu chuẩn (common.methods->open) sẽ tiếp tục mở thiết bị camera bằng phiên bản mới nhất được hỗ trợ, cũng là phiên bản được liệt kê trong camera_info_t.device_version.

2.2

Phiên bản mô-đun camera này bổ sung khả năng hỗ trợ thẻ của nhà cung cấp từ mô-đun và không dùng vendor_tag_query_ops cũ nữa. Trước đây, bạn chỉ có thể truy cập vào thẻ này khi thiết bị đang mở.

2.1

Phiên bản mô-đun camera này bổ sung tính năng hỗ trợ các lệnh gọi lại không đồng bộ cho khung từ mô-đun HAL camera. Mô-đun này được dùng để thông báo cho khung về các thay đổi đối với trạng thái mô-đun camera. Các mô-đun cung cấp phương thức set_callbacks() hợp lệ phải báo cáo ít nhất số phiên bản này.

2

Các mô-đun camera báo cáo số phiên bản này sẽ triển khai phiên bản thứ hai của giao diện HAL mô-đun camera. Các thiết bị camera có thể mở thông qua mô-đun này có thể hỗ trợ phiên bản 1.0 hoặc phiên bản 2.0 của giao diện HAL thiết bị camera. Trường device_version của camera_info luôn hợp lệ; trường static_camera_characteristics của camera_info sẽ hợp lệ nếu trường device_version là 2.0 trở lên.

1.0

Các mô-đun camera báo cáo những số phiên bản này sẽ triển khai giao diện HAL mô-đun camera ban đầu. Tất cả các thiết bị camera có thể mở được thông qua mô-đun này chỉ hỗ trợ phiên bản 1 của HAL thiết bị camera. Các trường device_version và static_camera_characteristics của camera_info không hợp lệ. Chỉ có API android.hardware.Camera mới được mô-đun này và các thiết bị của mô-đun hỗ trợ.