TestingCamera2 is a test application for the Android camera2 API (android.hardware.camera2.*).

1. Overview

The goal of Testingcamera2 is to allow all API primitives and behaviors to be excercised through
a reasonable UI, and allow simple demos and test cases to be built on top of it.

The concepts the application uses match the concepts of the API itself, so any given configuration
in the application can easily be reproduced directly with the camera2 API.

2. UI concepts:

The UI is divided into two panels, organized either side-by-side (in landscape orientations) or
above each other (in portrait orientations).

The left (or above) panel generally displays output from the camera subsystem, while the right
(or below) panel generally has controls for interacting with the camera subsystem.

Each category of object in the API is configured through a pane dedicated to that category; the
panes are grouped in lists by category, and can be added, removed, or collapsed from view
arbitrarily.

The left pane contains target panes along with the app's overall log pane.  The right pane contains
camera, request, burst, and utility panes.

The basic operation of the app is as follows:

  1. Add a camera pane, select camera to use
  2. Add at least one target pane, and for each, select the kind of target desired and its
     configuration options.
  3. Open and configure the camera from the camera pane
  4. Add a request pane, select the desired camera and targets, and the desired use case template.
  5. Start capturing images with either 'capture' (one-shot) or 'repeat' (continuous) buttons on
     the request.

The application also has a set of preset configurations that can be accessed from the top-right
dropdown menu, to speed up operation.

2.1. Camera panes

The camera pane includes device-level controls for a single camera, which can be selected from all
the cameras available on the Android device.  It allows for opening the device, reading out its
camera characteristics information, for configuring a set of targets, and for stopping or flushing
the camera.

2.2. Target panes

Target panes represent various destinations for camera data.  The kind of destination desired, and
the camera this target is meant for, are always available to select.  Each kind of destination
has its own set of controls for configuration and operation.

The pane always has a 'configure' toggle, which specifies whether that target pane will be included
in the selected camera's next configure operation. Until the target pane is included in a camera's
configuration, it cannot be used as a target for capture requests to that camera.

2.2.1. TextureView and SurfaceView targets

These are basic outputs generally used for camera preview; each is simply configured by the size
of buffers it requests from the camera.

2.2.2. ImageReader target

This is the basic still capture output, used for JPEG or uncompressed data that needs to be
application-accessible. It is simply configured with the desired output format, and the size.

2.2.3. MediaCodec and MediaRecorder targes

These are video recording targets, which use the Android device's video encoding APIs to create
video files.

2.2.4. RenderScript target

This target sends camera data to a RenderScript Allocation, from which it can be efficiently
processed by Android's RenderScript APIs.

2.3. Request panes

Request panes are used to set up the configuration for a single camera capture request. It includes
all the settings required for the camera device to capture a frame of data. It contains selectors
for the camera to send the request to, and then which of the configured target panes to use for
image output.  A given request can send data to any subset of the configured targets, but it
must include at least one target.

The camera device provides default values for all the request settings for various use cases; the
starting template can be selected from the dropdown.

Once a camera has been opened and configured, and the correct target(s) has been selected for the
request, the request can be sent to the camera with either the capture or repeat buttons.

Capture is a one-shot operation, which simply instructs the camera to capture a single frame of
data. This is commonly used for high-resolution snapshots, for triggering autofocus, or other
single-occurance events. Captures are queued and processed in FIFO order.

Repeat is a continuous operation, where the camera device continually captures the images using
the same request settings.  These have lower priority than captures, so if some request is actively
repeating, other requests can still use the 'capture' action to trigger single captures. Another
request triggering repeat will pre-empt any previous repeat actions by other requests.

To stop repeating, use the camera pane's stop method.

2.4. Burst panes

Burst panes simply aggregate together a set of requests into a single high-speed burst. Bursts
are captured atomically with no intervening other requests.  Similarly to single requests, they
can be one-shot or continuous.

The burst pane contains the target camera to send the burst to, and then allows including one or
more requests into the burst, from the list of requests that target the chosen camera.

2.5. Utility panes

Utility panes are catchall panes, which can implement various kinds of ease-of-use functionality,
such as implementing simple autofocus operation, still capture sequencing, or other high-level
functions.

2.6. Configuration load/save

TestingCamera2 supports loading a predefined set of panes from an XML definition. The definitions
can either be one of the default included sets, or located on the device SD card.

3. Internal architecture

Each pane is a specialized view, with a few generic methods for setting them up and notifying them
of changes in other panes.  Panes are tracked by a global pane tracker, which allows individual
panes to notify others of status changes (such as a change in the selected camera, so that all
panes targeting that camera pane can update their displayed settings choices), to find panes of
given types, and so on.

The operation of the camera devices is centralized in a single camera ops class, which keeps track
of open devices, notifies panes about changes to camera device status, and allows the utility panes
to intercept/override camera device operations as desired.