Android-Camera | Android Camera , OpenGL , Graphics | Graphics library

There's no reason you can't keep using the deprecated version of createCaptureSession - it works just as well as it did before. You'll just have to ignore the Android Studio deprecation warnings.

Basically, over time, we kept having to add more overloads of createCaptureSession with more and more variations of parameters and optional parameters, and it was getting excessive.

So we created SessionConfiguration as a configuration object that's more flexible over time (easier to add new parameters to it), set up one more createCaptureSession that accepts that, and deprecated all the prior versions to direct folks to the one we'd add today if we were designing the API again.

If you want to use the newest option, then you can take a look at OutputConfiguration (it just wraps the list of output Surfaces plus some other optional settings) - you can build one with just the surface you put in the Arrays.asList() call in your sample code.

But you can just keep using what you have - we won't actually break the old methods.

The image is received in JPEG format (as specified in the first line). Android uses YUV (to be more exact, YCbCr) color space for JPEG. Jpeg size is variable, it is compressed with lossy compression, and you have very little control over the level of compression.

Normally, you receive a JPEG buffer in onImageAvailable() and decode this JPEG to receive a Bitmap. You can get pixels of this Bitmap as an int array of packed SRGB pixels. The format for this array will be ARGB_8888. You don't need JNI to convert it to BGR, see this answer.

You can access Bitmap objects from C++, see ndk/reference/group/bitmap. There you can find the pixel format of this bitmap. If it was decoded from JPEG, you should expect this to be ANDROID_BITMAP_FORMAT_RGBA_8888.

In general, no. The actual hardware processing pipelines vary a great deal between different chip manufacturers and chip versions even from the same manufacturer. Plus each Android device maker then adds their own software on top of that.
And often, it's not possible to dump outputs from every step of the process, only some of them.

So making a consistent API for fetching this isn't very feasible, and the camera2 API doesn't have support for it.

You can somewhat simulate it by turning things like noise reduction entirely off (if supported by the device) and capturing multiple images, but that of course isn't as good as multiple versions of a single capture.

They're both viable. "Better" depends on a bunch of factors such as the size of the codebase, and how many different places in the code will be wanting to use the session and device.

There's some minor overhead in sending the callback to the camera handler thread, plus more boilerplate to write, so for smaller apps, just making calls from whatever thread you're in and synchronizing appropriately works fine.

However, as your app's complexity grows, it starts becoming attractive to keep all interaction with the camera API to a single thread; not just because you don't have to synchronize explicitly, but because it's easier to reason about ownership, the state of the system, and so on, if every interaction with the camera object happens on the same thread. Also, since some of the camera API methods can block for extended time periods, you really don't want to freeze your UI for that long anyway. So sending the calls to another thread is valuable.

So it's a tradeoff of some extra boilerplate + minor overhead vs. inability to centralize camera code in one place for simplicity and smoothness.

There's is no renderers in Uno: simply add your native control in the XAML and it should work unchanged.

There's a NativeView test in Uno you can check here, which is used here in XAML.

You can even set native properties directly in XAML, but bindings won't work on those.

If you need bindings, you can create a DependencyProperty and use the callback to set the native value.

CameraX has gone through some changes since it was first introduced last year, this is normal since it was still in Alpha, the API surface was changing a bit throughout the alpha versions, but since it's gone into beta, its public API has become more stable.

Going back to your question, binding and unbinding use cases in CameraX is no longer done through the CameraX class, but instead, it is now done using ProcessCameraProvider.bindToLifecycle() to bind one or multiple use cases to a lifecycle, ProcessCameraProvider.unbind() to unbind one or multiple use cases, and ProcessCameraProvider.unbindAll() to unbind all bound use cases.

The tutorials you're using as reference are outdated, even the video from last year's google I/O is outdated, since the code snippets in it are referencing CameraX's first alpha version. However, the link of the codelab you mentioned is -almost- up to date, it's the official CameraX codelab that's maintained by Google. You can also take a look at the official documentation of CameraX, it's more up to date that the tutorials you referenced.

Tested recorded videos with different methods and found out that the newest method from the latest sample is incorrect for landscape video recording, it plays videos upside down

I decided to update old method that uses deprecated camera api to use camera2 api (works for 21+ API) and use it in my project

Try with this method:

To enable or disable the flash during an image capture after you've created an ImageCapture instance and bound it to a lifecycle, you can use ImageCapture.setFlashMode(boolean).

Regarding your question about the difference between setting the flash mode before vs after binding the ImageCapture use case, AFAIK there isn't much of a difference really. When you take a picture by calling ImageCapture.takePicture(), a capture request is built using different configuration parameters, one of them is the flash mode. So as long as the flash mode is set before this call (ImageCapture.takePicture()), the output of the capture request should be the same.

CameraX currently uses Camera2 under the hood, to better understand how the flash mode is set when taking a picture, you can take a look at CaptureRequest.FLASH_MODE.