-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
App Crash on capture #917
Comments
Can you share a full stacktrace or logcat logs for your app starting approximately from the Are you sure that the activity simply isn't being closed (which is an documented behaviour and should be expected)? If this the case, the camera app should work properly and it will write the result to disk. When the camera activity closes and returns to your app, the app's activity needs to be recreated, which means the webview needs to be recreated and reloaded. When this happen the result will be supplied in the
Could just be a side effect of the activity closing. |
Thank you for your response ! I’ve added some extra logging to track the process more closely, especially around the getPicture call. I’m sharing the exported log file as an attachment so you can see the full trace of what’s happening from that point onward. It appears that the activity might indeed be closing, as you mentioned, potentially due to memory constraints. Xiaomi-M2006C3LG-Android-10_2024-11-07_152402.txt Let me know if there’s anything specific you’d like me to test or if there’s further information needed. |
I'm pretty confident the "crash" is a red herring. It might be triggering the crash callback from the OS killing the activity, even though that's an expected behaviour when working with intents. While using an intent it's not guaranteed for the app to stop but the OS reserves the right to kill it if it deems it necessary. If you enable the developer options on Android, you can enable the I glanced through the logs and I see:
Note the timestamp: 1730989421 Few seconds later:
We see this, but this is to be expected since the activity is stopped and/or stopping. Fast forward a bit:
here the activity has restarted, since the webview is requesting presumably your home/content src page. It's a bit hard to visualise what the app is doing from the logcat logs but I suspect that after the picture is taken and accepted, the app does come back to the Cordova webview view, just that perhaps your state has been reset? If so then that's the activity being killed and recreated when the camera's activity is done, and the window.document.addEventListener('resume', (e) => {
console.log(e.pendingResult);
}); Again this flow can be tested when using the |
Bug Report
Problem
What is expected to happen?
The camera should open, capture a high-quality photo, and return the captured image URI to the application without causing an out-of-memory (OOM) crash.
What does actually happen?
On a Redmi 9A device, the application crashes right after pressing the capture button in the camera interface, before reaching onActivityResult. The crash log indicates an OOM error.
Information
Log Output:
Command or Code
Environment, Platform, Device
Version information
Checklist
The text was updated successfully, but these errors were encountered: