1TestingCamera2 is a test application for the Android camera2 API (android.hardware.camera2.*). 2 31. Overview 4 5The goal of Testingcamera2 is to allow all API primitives and behaviors to be excercised through 6a reasonable UI, and allow simple demos and test cases to be built on top of it. 7 8The concepts the application uses match the concepts of the API itself, so any given configuration 9in the application can easily be reproduced directly with the camera2 API. 10 112. UI concepts: 12 13The UI is divided into two panels, organized either side-by-side (in landscape orientations) or 14above each other (in portrait orientations). 15 16The left (or above) panel generally displays output from the camera subsystem, while the right 17(or below) panel generally has controls for interacting with the camera subsystem. 18 19Each category of object in the API is configured through a pane dedicated to that category; the 20panes are grouped in lists by category, and can be added, removed, or collapsed from view 21arbitrarily. 22 23The left pane contains target panes along with the app's overall log pane. The right pane contains 24camera, request, burst, and utility panes. 25 26The basic operation of the app is as follows: 27 28 1. Add a camera pane, select camera to use 29 2. Add at least one target pane, and for each, select the kind of target desired and its 30 configuration options. 31 3. Open and configure the camera from the camera pane 32 4. Add a request pane, select the desired camera and targets, and the desired use case template. 33 5. Start capturing images with either 'capture' (one-shot) or 'repeat' (continuous) buttons on 34 the request. 35 36The application also has a set of preset configurations that can be accessed from the top-right 37dropdown menu, to speed up operation. 38 392.1. Camera panes 40 41The camera pane includes device-level controls for a single camera, which can be selected from all 42the cameras available on the Android device. It allows for opening the device, reading out its 43camera characteristics information, for configuring a set of targets, and for stopping or flushing 44the camera. 45 462.2. Target panes 47 48Target panes represent various destinations for camera data. The kind of destination desired, and 49the camera this target is meant for, are always available to select. Each kind of destination 50has its own set of controls for configuration and operation. 51 52The pane always has a 'configure' toggle, which specifies whether that target pane will be included 53in the selected camera's next configure operation. Until the target pane is included in a camera's 54configuration, it cannot be used as a target for capture requests to that camera. 55 562.2.1. TextureView and SurfaceView targets 57 58These are basic outputs generally used for camera preview; each is simply configured by the size 59of buffers it requests from the camera. 60 612.2.2. ImageReader target 62 63This is the basic still capture output, used for JPEG or uncompressed data that needs to be 64application-accessible. It is simply configured with the desired output format, and the size. 65 662.2.3. MediaCodec and MediaRecorder targes 67 68These are video recording targets, which use the Android device's video encoding APIs to create 69video files. 70 712.2.4. RenderScript target 72 73This target sends camera data to a RenderScript Allocation, from which it can be efficiently 74processed by Android's RenderScript APIs. 75 762.3. Request panes 77 78Request panes are used to set up the configuration for a single camera capture request. It includes 79all the settings required for the camera device to capture a frame of data. It contains selectors 80for the camera to send the request to, and then which of the configured target panes to use for 81image output. A given request can send data to any subset of the configured targets, but it 82must include at least one target. 83 84The camera device provides default values for all the request settings for various use cases; the 85starting template can be selected from the dropdown. 86 87Once a camera has been opened and configured, and the correct target(s) has been selected for the 88request, the request can be sent to the camera with either the capture or repeat buttons. 89 90Capture is a one-shot operation, which simply instructs the camera to capture a single frame of 91data. This is commonly used for high-resolution snapshots, for triggering autofocus, or other 92single-occurance events. Captures are queued and processed in FIFO order. 93 94Repeat is a continuous operation, where the camera device continually captures the images using 95the same request settings. These have lower priority than captures, so if some request is actively 96repeating, other requests can still use the 'capture' action to trigger single captures. Another 97request triggering repeat will pre-empt any previous repeat actions by other requests. 98 99To stop repeating, use the camera pane's stop method. 100 1012.4. Burst panes 102 103Burst panes simply aggregate together a set of requests into a single high-speed burst. Bursts 104are captured atomically with no intervening other requests. Similarly to single requests, they 105can be one-shot or continuous. 106 107The burst pane contains the target camera to send the burst to, and then allows including one or 108more requests into the burst, from the list of requests that target the chosen camera. 109 1102.5. Utility panes 111 112Utility panes are catchall panes, which can implement various kinds of ease-of-use functionality, 113such as implementing simple autofocus operation, still capture sequencing, or other high-level 114functions. 115 1162.6. Configuration load/save 117 118TestingCamera2 supports loading a predefined set of panes from an XML definition. The definitions 119can either be one of the default included sets, or located on the device SD card. 120 1213. Internal architecture 122 123Each pane is a specialized view, with a few generic methods for setting them up and notifying them 124of changes in other panes. Panes are tracked by a global pane tracker, which allows individual 125panes to notify others of status changes (such as a change in the selected camera, so that all 126panes targeting that camera pane can update their displayed settings choices), to find panes of 127given types, and so on. 128 129The operation of the camera devices is centralized in a single camera ops class, which keeps track 130of open devices, notifies panes about changes to camera device status, and allows the utility panes 131to intercept/override camera device operations as desired. 132 133