Home | History | Annotate | only in /pdk/apps/TestingCamera2
Up to higher level directory
NameDateSize
Android.mk21-Oct-20161,017
AndroidManifest.xml21-Oct-20162.5K
README.txt21-Oct-20166.3K
res/21-Oct-2016
src/21-Oct-2016

README.txt

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