This is because there are two CameraCaptureSession objects in VideoCaptureCamera2.java, 
one for preview (triggered at [1]) and another one for still image capture  (created 
at [2]).  We alternate between sessions for capturing because we don't know the still 
image resolution at the time the preview session is created (and the resolution is 
needed to create the session), we only get to know this value upon takePhoto() [3].
When the sessions alternate, the flash has a moment of being switched off -- confirmed
for my sailfish (Pixel L) and angler (Nexus 6P).

Camera apps usually have single preview + capture session and take photos at the max
resolution, so they don't have this problem.

Since this is essentially coming from the same root cause as the issue with the flash
not working properly in devices using Camera2 API, I'll merge it in that bug, on
which I'm working.


[1] https://cs.chromium.org/chromium/src/media/capture/video/android/java/src/org/chromium/media/VideoCaptureCamera2.java?q=videocapturecamera2.jav&sq=package:chromium&dr&l=389
[2] https://cs.chromium.org/chromium/src/media/capture/video/android/java/src/org/chromium/media/VideoCaptureCamera2.java?q=videocapturecamera2.jav&sq=package:chromium&dr&l=1119
[3] https://cs.chromium.org/chromium/src/media/capture/video/android/java/src/org/chromium/media/VideoCaptureCamera2.java?q=videocapturecamera2.jav&sq=package:chromium&dr&l=1082

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c69a479170be23ec6fed72bf863b18c44cdbd694

commit c69a479170be23ec6fed72bf863b18c44cdbd694
Author: Miguel Casas-Sanchez <mcasas@chromium.org>
Date: Wed Jun 07 03:04:59 2017

Image Capture: refactor Android Camera2 code to simplify Session mgmt

ToT has two CaptureSessions, one for preview and one for photo,
that are alternated upon takePhoto(). Each has a CaptureRequest
(a "request" is like a config "packet"). This CL moves to having
a single Session with two Requests (one for preview and one for 
photo) and adds a third for the needed flash calibration round
(call a "precapture" in the API). 

The new Request dance is, w/o flash light:
 preview --> capture --> preview
and with flash:
 preview --> precapture --> capture --> preview.

Each Request is coupled with a persistent ImageReader: the existing 
|mImageCapture| (renamed to |mPreviewReader|) and a new |mPhotoCapture|. 
Having a single Session is good in itself because it takes 
significant time to change between them (~150ms!).

Other minor thingies:

- |mReconfigureCaptureTask| and CrPhotoSessionListener are 
not necessary and removed.
- no need to keep |mPreviewRequest| and |mPreviewRequestBuilder|,
so we just have the latter.
- new service function restartPreview() to bundle up the try-catch.

Bug: 720250,  721227 
Change-Id: Icaec2410942fe478dee73d0b0335987f963bb9bb
Reviewed-on: https://chromium-review.googlesource.com/526280
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#477533}
[modify] https://crrev.com/c69a479170be23ec6fed72bf863b18c44cdbd694/media/capture/video/android/java/src/org/chromium/media/VideoCaptureCamera2.java

#3 sorted it out, so let's deduplicate it :P