Hello everyone, I hope you all are doing well. Please we have a camera Implementation in our Project...

# compose-android

[shock 11]

Hello everyone, I hope you all are doing well.
Please we have a camera Implementation in our Project that makes use of the ActivityResultsApis(specifically the ActivityResultContracts.TakePicture()) for taking a photo and also picking a photo from the gallery. However this does not work at all on my device. It is a Redmi 8A MIUI VERSION 12.5.2 Android 10. But it works perfectly well on my Boss's and my teammates devices, even tried it on my mum's device(also an android 10). It works. But not on mine, what it does on mine is that after taking the photo, it takes quite sometime to return to the app and in the end, it returns an empty URI(this is for the sample project I have created). But this works perfectly on other devices I have tested so far. I have created a sample project that recreates this issue, it is very simple code and it has everything including my manifests setting and all. I will share that in a thread

[shock 11]

This is a sample project that recreates this problem.
https://github.com/daniel-iroka/JetpackCompose-Camera-bug

[shock 11]

I also have videos showcasing this behaviour on two different devices despite the fact that they are the same android version. I will share that now

[Ian Lake]

If you change your capturedUri from remember to rememberSaveable, does that work? Camera apps historically are so memory intensive that they can easily kick every app out of memory

[Ian Lake]

You can also test a similar scenario by rotating your device when you're on the camera app (which will, by default, restart your activity) since that would also destroy any remembered value but keep something you actually save

[shock 11]

Okay thanks, let me try that and see

[shock 11]

I just tried it and it still doesn't work

[shock 11]

But I've just checked my logs and seen what you are saying is right. Its as if the app's process is being killed and recreated when I take the picture and try to go back to the app

[shock 11]

This is my logs from the moment I start the camera

[shock 11]

But for the second thing you suggested, I can't seem to rotate the camera app, instead it is just the camera's angle that is rotated

[Ian Lake]

Well, if you leave your app rotated when you return back to it (and have rotation enabled, don't handle config changes, etc.), then your activity will be recreated in the new orientation

[shock 11]

Okay yes I just confirmed that(not with my device). I did exactly just as you said and the image is not being returned

[shock 11]

But not with the rememberSaveable function, just the remember

[shock 11]

But I tried using the rememberSaveable function on my device and its still the same result

[shock 11]

It just worked now when I changed the imageUri state to rememberSaveable, and it is the one that I am launching the camera activity directly with. I guess its the one that needs to be changed

[shock 11]

The image is being saved smoothly and from the logs, the app's process doesn't seem to be killed. Thank you!

[shock 11]

So I guess that is what is happening 🤔, no wonder in our project, it seemed as if the whole app was starting from the beginning because it was showing the Root/Splash screen after I returned to the app. Now to try it in the main project and see the result

[shock 11]

Thanks again though! At least, I've learnt something new today. I also don't need to use rememberSaveable for the "capturedUri" state but just the uri that I am writing the file too and directly launching the camera activity with.

[shock 11]

But having known that the camera apps(if I'm not mistaken, the device's camera app) can be memory intensive, is there any alternative that maybe can offer like a slightly better performance?

[Ian Lake]

Sorry, I thought your capturedUri was where you were storing your image, I should have recommended imageUri

[Ian Lake]

But all this is just how it works - you'll note the Activity Result guide actually specifically calls out the camera as why the Activity Result APIs are written as they are (where the entire process can and will be killed):

When starting an activity for a result, it is possible—and, in cases of memory-intensive operations such as camera usage, almost certain—that your process and your activity will be destroyed due to low memory.

For this reason, the Activity Result APIs decouple the result callback from the place in your code where you launch the other activity.

[shock 11]

I see, it makes a lot of sense now. Thanks