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.

Hi,

Thanks for the feedback. QualitySelector.isQualitySupported() can only know whether the device support this quality, but the final selected quality is still constrained by UseCase combinations when ProcessCameraProvider.bindToLifecycle is called. It depends on camera hardware level and the supported surface combinations defined in camera2 CameraDevice regular-capture.

For example, assume isQualitySupported(UHD) returns true on a device. When trying to bind use cases with QualitySelector only contains UHD, you may get below results for different combinations

• Preview + VideoCapture(UHD) => success
• Preview + ImageCapture + VideoCapture(UHD) => fail
• Preview + ImageCapture + VideoCapture(FHD) => success

In your case, I think you want to know in advance what qualities are supported under a certain use cases combination (ex: Preview + VideoCapture). However, there is not yet a convenient API to query about this. Currently you can create a VideoCapture with a single quality (QualitySelector.from(quality)) and then bind the use cases you want, use try-catch on ProcessCameraProvider.bindToLifecycle() to know if the combination is supported (ProcessCameraProvider.bindToLifecycle() will throw an exception if the combination is not supported).

However, this method will open camera when the combination is supported. It would be better to have an API that only checks for support without opening camera. There is a bug related to such API requirement. See https://issuetracker.google.com/204274197. Add you to the CC list for updates.

Let us know if you have any questions.

Leo

Pixels appear to be capable of taking photos while recording 4k video and we're still seeing 4k resolution not being used on them when we try to use QualitySelector with UHD as the main choice and FHD as a fallback. It's likely that what you're describing does occur on some devices but I don't think it explains the QualitySelector issue we're seeing on Pixels.

If you try our app from https://github.com/GrapheneOS/Camera, it's able to use 4k recording on Pixels while doing image capture. We do fall back to video + preview if video + preview + image capture fails to load, but it doesn't happen for 4k on Pixels when using QualitySelector.from(Quality.UHD), only when doing QualitySelector.from(Quality.UHD, fallback) or using a list of qualities. It seems like QualitySelector never uses the first choice when there are fallbacks. That's the behavior we're seeing at least. Are you not able to replicate it?

This sounds like a bug. I will investigate it and get back to you.

Thanks

The issue happens when combining ImageCapture + VideoCapture.

In a FULL level camera device, there are two possible combinations for Preview + VideoCapture + ImageCapture. (refer to CameraDevice regular-capture.)

1. (PRIV, PREVIEW) + (PRIV, RECORD) + (JPEG, RECORD)
2. (PRIV, PREVIEW) + (PRIV, PREVIEW) + (JPEG, MAXIMUM)

MAXIMUM > RECORD > PREVIEW

In the current CameraX settings, ImageCapture has higher surface occupancy priority than VideoCapture by default. That means ImageCapture has higher priority to choose resolution than VideoCapture. When QualitySelector contains multiple qualities as candidates, such as

QualitySelector.from(Quality.UHD, FallbackStrategy.lowerQualityOrHigherThan(Quality.UHD)))

It means VideoCapture can accept UHD, FHD, HD, SD. CameraX auto-resolution mechanism will then adopt combination (2) because ImageCapture has higher priority. i.e. ImageCapture gets MAXIMUM size and VideoCapture gets Preview size (FHD).

For

QualitySelector.from(Quality.UHD)

Since there is only one option UHD (RECORD size) for VideoCapture, combination (2) can't be met and combination (1) is adopted. i.e. both ImageCapture and VideoCapture gets RECORD size.

will have a solution to fix this.

The fix will be included in June release.