The camera.v4l2 library implements a Camera HALv3 using the Video For Linux 2 (V4L2) interface. This allows it to theoretically work with a wide variety of devices, though the limitations of V4L2 introduce some caveats, causing this HAL to not be fully spec-compliant.
To ensure the HAL is built for a device, include the following in your
USE_CAMERA_V4L2_HAL := true PRODUCT_PACKAGES += camera.v4l2 PRODUCT_PROPERTY_OVERRIDES += ro.hardware.camera=v4l2
The first line ensures the V4L2 HAL module is visible to the build system. This prevents checkbuilds on devices that don't have the necessary support from failing. The product packages tells the build system to include the V4L2 HALv3 library in the system image. The final line tells the hardware manager to load the V4L2 HAL instead of a default Camera HAL.
Devices and cameras wishing to use this HAL must meet the following requirements:
There are three large pieces to the V4L2 Camera HAL: the general HALv3 Camera & HAL code, the specific implementation using V4L2, and the Metadata system.
For context, you may also wish to read some of the documentation in libhardware/include/camera3.h about how the framework interacts with the HAL.
The camera and HAL interfaces are implemented by the Camera and V4L2CameraHAL classes.
The V4L2CameraHAL class deals primarily with initialization of the system. On creation, it searches /dev/video* nodes for ones with the necessary capabilities. These are then all presented to the framework as available for use. Further operations are passed to the individual Cameras as appropriate.
The Camera class implements the general logic for handling the camera - opening and closing, configuring streams, preparing and tracking requests, etc. While it handles the logistics surrounding the camera, actual image capture and settings logic are implemented by calling down into the V4L2 Camera. The Camera (using helper classes) enforces restrictions given in the Metadata initialized by the V4L2Camera, such as limits on the number of in-flight requests per stream. Notably, this means you should be able to replace the V4L2 implementation with something else, and as long as you fill in the metadata correctly the Camera class should “just work”.
The V4L2Camera class is the implementation of all the capture functionality. It includes some methods for the Camera class to verify the setup, but the bulk of the class is the request queue. The Camera class submits CaptureRequests as they come in and are verified. The V4L2Camera runs these through a three stage asynchronous pipeline:
Much of this work is aided by the V4L2Wrapper helper class, which provides simpler inputs and outputs around the V4L2 ioctls based on their known use by the HAL; filling in common values automatically and extracting the information useful to the HAL from the results. This wrapper is also used to expose V4L2 controls to their corresponding Metadata components.
The Metadata subsystem attempts to organize and simplify handling of camera metadata (system/media/camera/docs/docs.html). At the top level is the Metadata class and the PartialMetadataInterface. The Metadata class provides high level interaction with the individual components - filling the static metadata, validating, getting, and setting settings, etc. The Metadata class passes all of these things on to the component PartialMetadataInterfaces, each of which filter for their specific metadata components and perform the requested task.
Some generalized metadata classes are provided to simplify common logic for this filtering and application. At a high level, there are three types:
The Metadata system uses further interfaces and subclasses to distinguish the variety of different functionalities necessary for different metadata tags.
This V4L2 Camera HAL implementation utilizes a metadata factory method. This method initializes all the 100+ required metadata components for basic HAL spec compliance. Most do nothing/report fixed values, but a few are hooked up to the V4L2 driver.
This HAL was initially designed for use with the Raspberry Pi camera module v2.1, so the fixed defaults are usually assigned based on that camera.