The camera service provider on Chrome OS is a standalone process that can be divided into two part:
Currently we have two major camera clients on Chrome OS: Chrome browser and Android. All the clients connect to the camera HAL adapter through the Camera Module Mojo IPC interface and the Camera Device Mojo IPC interface to access camera functions. The Mojo IPC interface is very similar to the Android camera HAL v3 APIs.
Usually the platform-specific camera HAL is accompanied with a proprietary camera 3A (auto focus, auto exposure, and auto white-balance) library that provides the algorithms to control the camera subsystem for capturing high quality images. We isolate the camera 3A library in a separated sandboxed process for security consideration. The camera HAL accesses the camera 3A library through the Camera Algorithm Mojo IPC interface.
The camera HAL needs to generate JPEG images when processing still shot requests. On Chrome OS the JPEG codec service, if supported on the platform, is provided by the GPU process in Chrome browser. We provide libraries to handle JPEG encoding and decoding: On platform that supports hardware-accelerated JPEG encoder/decoder, the JPEG libraries connect to the Chrome GPU process through Mojo IPC channels to encode/decode JPEG images; otherwise the JPEG encoding/decoding is done through software.
The Chrome OS camera HAL are essentially the following shared libraries, plus and dependencies required by them:
camera_hal.sothat provides the camera HAL interface. This is very similar to a regular Android camera HAL. (Required)
libcam_algo.sothat provides the camera algorithm interface for the isolated camera 3A library. (Required if the camera HAL requires 3A library to work).
We provide the following packages that are required to build the camera HAL:
A package that installs all the necessary Android headers files and libraries required by the camera HAL.
A package that provides all the base functionality and libraries for running the camera HAL stack. Check the header files for the functions provided. Some important ones are:
Functions to access the isolated camera 3A library if the camera HAL requires it to work. See the APIs for more details.
A replacement for Android gralloc. The library provides APIs to import and map buffer handles received in capture requests.
JPEG decoder and encoder APIs that adapt to either software or hardware-accelerated implementations based on the platform capability.
A port of the Android
To add a new camera HAL for a new platform, one needs to upload the source code of the camera HAL to the camera HAL directory (1P, 3P).
Examples: Intel camera HAL, USB camera HAL.
After the camera HAL source code is uploaded, one needs to add corresponding packages to build and install the camera HAL and the required libraries. On Chrome OS, packages are managed by ebuild files. The following ebuild files are required for a new camera HAL:
A ebuild file for the newly added camera HAL. The ebuild file is used to build and install the platform specific camera HAL and the camera algorithm (
libcam_algo.so) shared libraries into the board sysroot. To integrate the camera HAL into the OS image, a
virtual/cros-camera-hal ebuild that includes the newly added camera HAL as
RDEPEND is required in the baseboard or board overlay.
Camera HAL ebuild examples: Intel Kabylake camera HAL, USB camera HAL
Camera HAL virtual ebuild example: Intel Kabylake camera HAL virtual package
For board-specific camera HAL config files, we have the
virtual/cros-camera-hal-configs ebuild. One can add a new ebuild to install the board-specific camera HAL config files, and list the new ebuild as
RDEPEND of the virtual ebuild.
Camera HAL config ebuild example: Intel Kabylake camera HAL configs
Camera HAL config virtual ebuild example: Intel Kabylake camera HAL configs virtual package