IssueTracker

Hi Doudera,

Thank you for reporting this issue. It is working as intended. This is because the state of CameraControl follows Camera. Once the Camera is closed, all settings will be restored, just like the settings of the focus area and zoom level. The app can restore the torch state by resetting torch at the time of activity onResume.

Hi Doudera, Thank you for the detail description. It sounds like some problem in the code. I will investigate it more.

From the log, it shows the camera state

-> open -> enable torch -> close -> open

The torch was gone because it restarted the camera.

It needs to investigate more about why it open/close so frequently.

In CameraXBasic, it looks like the "cameraProvider.unbindAll()" call in CameraFragment.bindCameraUseCases() method will cause the camera close.

Since camera operation is in another thread, a timing causes the enableTorch() failed because the camera is in closed state at that moment.

It can be detected by checking the returned ListenableFuture result from cameraControl.enableTorch()

020-03-29 12:34:56.139 4946-4946/com.android.example.cameraxbasic E/CameraXBasic: enableTorch
2020-03-29 12:34:56.225 4946-5035/com.android.example.cameraxbasic D/Camera: Transitioning camera internal state: OPENED --> CLOSING
2020-03-29 12:34:56.226 4946-4946/com.android.example.cameraxbasic E/CameraXBasic: enableTorch fail by java.util.concurrent.ExecutionException: androidx.camera.core.CameraControl$OperationCanceledException: Camera is not active.
    java.util.concurrent.ExecutionException: androidx.camera.core.CameraControl$OperationCanceledException: Camera is not active.
        at androidx.concurrent.futures.AbstractResolvableFuture.getDoneValue(AbstractResolvableFuture.java:518)
        at androidx.concurrent.futures.AbstractResolvableFuture.get(AbstractResolvableFuture.java:475)
        at androidx.concurrent.futures.CallbackToFutureAdapter$SafeFuture.get(CallbackToFutureAdapter.java:199)
        at com.android.example.cameraxbasic.fragments.CameraFragment$bindCameraUseCases$1$2$1.run(CameraFragment.kt:310)
        at android.os.Handler.handleCallback(Handler.java:907)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loop(Looper.java:216)
        at android.app.ActivityThread.main(ActivityThread.java:7476)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:549)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:968)
     Caused by: androidx.camera.core.CameraControl$OperationCanceledException: Camera is not active.
        at androidx.camera.camera2.internal.TorchControl.setActive(TorchControl.java:112)
        at androidx.camera.camera2.internal.Camera2CameraControl.setActive(Camera2CameraControl.java:135)
        at androidx.camera.camera2.internal.Camera2CameraImpl.tryRemoveOnlineUseCases(Camera2CameraImpl.java:727)
        at androidx.camera.camera2.internal.Camera2CameraImpl.lambda$removeOnlineUseCase$13$Camera2CameraImpl(Camera2CameraImpl.java:699)
        at androidx.camera.camera2.internal.-$$Lambda$Camera2CameraImpl$5wc8VkOCNW87m5eLEZfzgWUl-nY.run(Unknown Source:4)
        at android.os.Handler.handleCallback(Handler.java:907)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loop(Looper.java:216)
        at android.os.HandlerThread.run(HandlerThread.java:67)

It is a defect that CameraX should guarantee the order of the camera request.

Another topic is that why camera will be closed when resuming the CameraFragment.

CameraX is lifecycle aware, if UseCases is bound and pause/resume the page, CameraX will restart those UseCases automatically. So actually it doesn't have to unbind and rebind those UseCases. Unbind and rebind UseCases causes it open camera twice and meet this timing issue. In CameraXBasic, it will unbind and rebind UseCases in onViewCreated().

It is easier to be done in an Activity, just put the bindToLifecycle(...) code in the Activity.onCreate(). For Fragment, maybe Fragment.onAttach() is something like Activity.onCreate, but not pretty sure if it is practical. Or alternatively, it has to unbind all use case in a paired callback such like Fragment.onDestroyView() to prevent Camera from being automatically opened when resuming.

For Huawei Mate 20 Lite it's HWSNE. Unfortunately, I'm unable to provide you info for Honor 9X.

Hi,

We're clarifying this issue with the camera framework team and need your further help to provide some more information. So that we can know all the details and might be able to improve the CTS tests to cover this in the future.

1. What is the problematic image size when capturing the image in target aspect ratio 4:3 setting?
2. Could you help to provide the JPEG supported sizes list of the Huawei Mate 20 Lite device? I'm not sure whether it is the same as you have been provided in b/161156062#comment4.
3. Could you provide a bugreport that is dumped right after operating to capture the problematic 4:3 image?

Thanks in advance.

Hi,

1. I didn't specify target resolution, but I've check with max available resolution (3840x5120) and custom one (1200x1600), both times the issue has occurred.
2. Yes, it is the same list I've provided.
3. In attachments.

Please let me know when you will have any plans to cover this issue.

Thanks. This issue will be targeted to be fixed in Dec release.

Thank you. I'm looking forward to it.

Hi,

Could you help to install and check whether the issue can be resolved by the attached apk?

What I modified:

1. Force CameraFragment#aspectRatio() to return AspectRatio.RATIO_4_3.
2. Do not use JPEG_ORIENTATION capture request parameter and rotate the output image according the target rotation setting. This is only applied to the Huawei Mate 20 Lite and Honor 9X devices by Build.BRAND and Build.MODEL.

Please take pictures in 0, 90 and 180 and also help to dump and extract logs with tag "b171492111-debug". So that I can analyze whether the solution work as expectation.

Thanks.

Friendly ping :)

Hi,

It won't stop the fix. The purpose is just to verify my solution can really resolve the problem since I do not have device to verify it. I'll still prepare the fix in the next release.

The solution has been merged in https://android-review.googlesource.com/c/platform/frameworks/support/+/1492739. Please wait for the next monthly release in Dec that will include it.

Hi,

Great news, it works on real users' devices. Thank you for resolving this.