App crashes randomly after taking a picture with the camera #665
Comments
|
Hey What are the camerasettings/options in your code? Kind regards |
|
Hi Pieter, Kind regards Oliver |
|
Happens to me as well, Pixel 4 Android 11 |
|
Updated Android SDK and build tools and the problem has gone. |
|
Doesn't help much in our Case. Sometimes we are able to record really long series of pictures (50 - 70) before the app breaks. |
|
Same here. This did not help with our issue. This might be related to issue #678 for iOS 14... We crash after 150 - 195 photos on Android 11.0. Have not had a chance to test Android 10.0. If helpful, please see attached for the devices and versions tested. 4th column is how many photos it takes to crash. Our users take about 1,500 photos per day. We used to get well over 1,000 photos on Android 9.0 and older. Environments tested here: Camera plugin 4.1.0 and 5.0.1
|
|
So far from what I can dig up, Is that it might be related to an older bug with Capacitor regarding removing event listeners while events are still being triggered. ionic-team/capacitor#1943 *** Collection <__NSArrayM: 0x283ccadf0> was mutated while being enumerated. (Copied from other bug issue) |
|
@keo9ren Hi. Have you found a workaround? We are experiencing the same problem and I wondered if you found something that might help to fix it. |
|
The only workaround so far is that the tablets won't be upgraded. |
|
Hello. I have seen this issue in our app as well. Could you guys try without destinationType: navigator.camera.DestinationType.FILE_URI Removing this option has improved the situation a lot. However I have a feeling that some devices behave better with this and some without it. |
|
We pushed an update to the Play Store having upgraded to Cordova Android 9 and 5.0.1 of the camera plugin and immediately started running into this issue with Android 10 devices. |
|
Maybe we should just focus on Android on this issue. My first guess is: and When processing the result, the plugin uses the null imageFilePath.
So maybe just storing and restoring imageUri and imageFilePath seperatly in the onSaveInstance and onRestore methods is enough. This is the stacktrace from my testing app https://github.com/PieterVanPoyer/cordova-camera-plugin-testing-app when the activity in the emulator is configured to be always destroyed when the camera opens. |
…Instance) and restore it back.
|
There is indeed a scenario that results in a NullPointerException and crashes the Android plugin. You can install and test the plugin (on Android) with next command. You could test it with next reproduction repo: Kind regards Pieter |
Test the https://github.com/PieterVanPoyer/cordova-camera-plugin-testing-app |
|
|
Hi @keo9ren @tenglandct |
I'm on leave this week but planning to test next week when I'm back working |
|
@PieterVanPoyer The Event.PendingResult is not empty only when the app is reloaded |
|
@maochong513 it seems like the desired behaviour. Before my fix the plugin crashes before sending the PendingResult event. I really do not understand your original comment about a crash. |
…Instance) and restore it back.
|
@maochong513 some commits from master were not yet on may branche. So it could lead to crashes. Now it is fixed. The branches are even. My MR is 2 commits ahead of master. |
|
test step: 2 ### The problem appeared after four or five pictures had been taken Information |
|
@maochong513 thanks for your testing, but your installation test steps are wrong. Kind regards |
Hi Pieter @PieterVanPoyer |
|
@maochong513 restarting of the app is normal. That is Android Lifecycle related stuff. Your app must be able to handle restarting the apps when camera is opened without data loss. see: https://cordova.apache.org/docs/en/latest/reference/cordova-plugin-camera/#android-quirks en https://cordova.apache.org/docs/en/dev/guide/platforms/android/index.html#lifecycle-guide Before my fix, the app crashed when being restarted when the camera was being processed. |
|
@PieterVanPoyer will try to test early this week. Have been on Christmas Holidays till today. Appreciate your effort! |
|
hi guys, am facing the same problem. if you guys have fixed, kindly share the dets. thanks in advance |
|
Hi, I also did not know that the restart of the app is basically by design. Maybe it's caused by low memory, we have only 400 MB available if our app is running, of the specific device. Our App can't handle restarts and we are in the lucky situation that we're able to switch to other devices. |
* GH-665 - store the imageFilePath when the app is paused (onSaveInstance) and restore it back. * Update src/android/CameraLauncher.java whitespace layout Co-authored-by: Tim Brust <github@timbrust.de> Co-authored-by: Tim Brust <github@timbrust.de>
|
hi @keo9ren Can you share the solution to your problem, I have not been able to solve it |
|
As mentioned here we have no real solution either. The restarts are by design on android (links and explanation are in the discussion above ). We just switched to devices with more RAM, that fixed it for us. |
|
i have the same issue.app crashes soon after image was captured. cordova cli Testing on Nokia 7.2 with |
|
am working on Cordova 9 platform . and use cordova -plugin-camera@5.0.0 Thank you |
|
@guillermohaad can you update the plugin-camera to v5.0.1? Then the saveToPhotoAlbum option can be enabled. |
|
hi @PieterVanPoyer thank you |
|
I've also updated the latest plugin 5.0.2, but the same problems occur on Android 10 (device - redmi note 7pro). The plugin 5.0.2. Forcefully close the application once we capture a photo. This happens on some specific devices. Please update the new version I'm waiting for the new version I'm waiting for your response, thanks |
|
Same here! The problem is ocurring only in Android 10 devices. When the photo is taken, the window of confirmation appears and I click in "Ok" option, app crash and restart :( I'm using: |
|
Hi all, Cordova 9.0.0 |
|
For ME there is a bug in the camera plugin. I fixed it for MY situation. This may or may not apply to yours. Scenario:
What I found and what I fixed: First look at ProcessResultFromCamera function -> these lines: It's using imageUri but saving imageFilePath? Maybe this is intended maybe not. I added a quick debug helper class to push out Toasts. I added Toasts all throughout CameraLauncher.java. I looked at onSaveInstanceState and noticed a couple things:
This would explain why we get the "filename cannot be null" as that specific exception is thrown in ExifInterface.java I believe. The Fix?? Update imageUri in onSaveInstanceState. Add imageFileName to onSaveInstanceState. Add imageFileName to onRestore here's the actual code to update/add in onSaveInstanceState: here's the code to ADD in onRestoreStateForActivityResult: |
|
@breautek still have the problem, can you re-open this issue ? |
|
That's not normal that the app crashes with this plugin, even if you manage all the details when the app reboots |
If the app is "rebooting", then you're not experiencing a crash. A native crash will generally cause the app to completely close and a dialog will appear with a message If this is what you're experiencing, there isn't anything Cordova can do. That is how Android works and this is something that all android developers needs to keep in mind, including native developers. Particularly when working with android intents that consumes a lot of resources. Cordova does expose a way to handle this situation, which sounds like you're already aware of.
If I misinterpreted and you actually do have a crash, I'd suggest opening a new issue with the issue form filled out. Do not simply create a ticket that references this ticket, that's pointless and doesn't actually tell us anything new. Linking to this ticket for context is helpful. Best to run the app using android studio so that we can have access to the native logs and capture the stack traces. We need to be able to confirm if the issue you're experiencing is in fact the same issue described in this ticket, and only then proceed further to figure out the "why". If you're unsure how to use android studio to capture stack traces, I'd suggest asking our Slack community for assistance. |
|
If you look at my post two or three up it details exactly what the problem is. It's a crash in the plugin. The app doesn't crash...but it never received the success or error callback so it just lingers. It is an activity life cycle event in the plugin. onSaveInstanceState isn't saving imageFileName properly and it never reloads it. And yes the Android OS is killing the app. That's causing imageFileName to be billed out because it's not being save properly and reloaded. Because of this ExifHelper.js throws an exception Look at my post a few up. |
|
@breautek thanks a lot for this synthesis.
The problem with rebooting is that it's really close to a crash, we loose the route and all the data filled by the user, so quite hard to provide a compelling user experience.
I can confirm that, it crashes on Samsung Tab1 (old tablets) and Lenovo TAB P11 Pro (really recent, 6G RAM, pictures of 40Mo).
Mains challenge is that it's hard to reproduce, because hardware Camera api can't be tested in simulator at the moment. Do you know a way ? Is there also a way to force images resolution in the simulator for Camera capture ?
=> There's really absolutely no way to prevent the reboot with Java native Android API or Java Android plugins ? Like maybe storing image in the hard memory and not using RAM, trying to prepare the device RAM for taking a picture, allow more RAM space for pictures capture, killing camera process before camera capture, etc... ? Because if it's really the case, that should really be a major Android issue for all their developers / users. I mean, when you have 6G RAM, and you can't take a picture of 40Mo without an app reboot, that's really surprising. => There's no issue about it in the Android community ? => How do the native Java Camera Api works ? Looks like only hybrids apps with this plugin face the problem, otherwise any app in the world should often see their apps reboot since Android 10 on many devices, which would be a major problem for Android users. Thanks a lot for your explanations ;) Other usefull links |
@tronious a fix has been merged for that full crash problem in the |
|
This is getting off-topic and not really the place to discuss this, so I'll make some final points and then I'll be locking this thread.
Again, that is the android lifecycle. It is easier to manage working completely in native, it is much harder to "restore" the webview state, but it is up to the android developer to handle serialize their state and reconstruct it later in the case that the OS decides it needs to kill the app activity. This is an app developer problem because this is simply something that cannot be solved generically.
No, this plugin relies on intents (that is, to delegate camera responsibility to an existing camera app that has camera permissions). This means it uses whatever settings the user has set in their chosen camera app. More on this later, to another question, with potentially a path forward for your case specifically.
The camera app already does this, but it obviously still needs the RAM to render the camera and snapping the photo before it it can save to the hard drive. In fact, the android application receives a file uri from the camera intent, not the photo binary itself.
This plugin doesn't use the Camera API directly. We use Camera intents. For those who aren't native developers, Intents is a way to delegate responsibilities to another app. So when you use the camera plugin, android actually puts your app into the background, and launches a completely different app to handle the camera action, then passes the results back to the app that made the request. Why do we do this? Well first it's the recommended approach by Android. It's recommended because the most apps do not have a reason to have direct access to the camera APIs. They are considered dangerous (in the privacy sense) and if your app simply just wants to snap a photo, it does not have justification to depend on those APIs. Using the camera permissions without necessary justification can be a grounds for the app to be rejected from the Google Play Store. Therefore this camera plugin uses the intent way, to delegate camera responsibilities to an already existing app (which most devices have). If a plugin DID declare the camera permissions, and used the camera APIs directly, you do have more control. You can pro-grammatically snap a photo without user action, you can work with image data in real time, and I assume you can also control the resolution as well. More importantly, you're app won't ever leave the foreground and therefore the OS won't decide to kill your activity (unless you literally run out of memory). Using camera APIs directly is not something Apache Cordova tries to solve, but there may be an existing plugin (or you can create your own) that uses the camera APIs directly, if you can convince Google that your app requires the dangerous camera permission. |
Bug Report
Problem
After taking a picture, pushing the OK Button (marked below) of camera-plugin crashes the app randomly.
What is expected to happen?
The picture should be available in the app for further action.
What does actually happen?
The app crashes.
Information
Command or Code
Environment, Platform, Device
Chrashes have first appeared on Samsung Galaxy Tab A (SM-T515) after Android 10 update.
Same device running android 9 seams to work fine.
Version information
Cordova Packages:
Project Installed Platforms:
Project Installed Plugins:
Environment:
Checklist
The text was updated successfully, but these errors were encountered: