Skip to content
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

Open
3 tasks done
jdevuono54 opened this issue Nov 6, 2024 · 3 comments
Open
3 tasks done

App Crash on capture #917

jdevuono54 opened this issue Nov 6, 2024 · 3 comments

Comments

@jdevuono54
Copy link

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

  • The crash happens before onActivityResult,, right after pressing the capture button

Log Output:

2024-11-06 11:21:18.432 29632-29784 cr_ChildProcessConn     [APP_NAME]                   W  onServiceDisconnected (crash or killed by oom): pid=29786 bindings:W  S
2024-11-06 11:21:18.671 29632-29632 chromium                [APP_NAME]                   E  [ERROR:aw_browser_terminator.cc(165)] Renderer process (29786) crash detected (code -1).

Command or Code

return new Promise((resolve, reject) => {
            navigator.camera.getPicture(path => {
                Filesystem.resolveUrl(path).then(resolve, reject);
            }, error => {

                if (error === 'No Image Selected'){ return resolve(null); }

                reject(error);
            }, {
                destinationType: Camera.DestinationType.FILE_URI,
                sourceType: Camera.PictureSourceType.CAMERA,
                quality: 100,
                allowEdit: false,
                correctOrientation: true,
                saveToPhotoAlbum: true,
                encodingType: Camera.EncodingType.JPEG,
                mediaType: Camera.MediaType.PICTURE
            });
        }) as unknown as Promise<Entry>;

Environment, Platform, Device

  • Device: Redmi 9A
  • Android Version: 10 (MIUI 12.0.17)
  • Cordova Plugins:
    • cordova-plugin-camera: ^8.0.0
    • cordova-plugin-file: ^8.0.1
  • Platform: Android

Version information

  • cordova-android: ^13.0.0

Checklist

  • I searched for existing GitHub issues
  • I updated all Cordova tooling to most recent version
  • I included all the necessary information above
@breautek
Copy link
Contributor

breautek commented Nov 6, 2024

Can you share a full stacktrace or logcat logs for your app starting approximately from the getPicture call?

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 resume event.

2024-11-06 11:21:18.432 29632-29784 cr_ChildProcessConn     [APP_NAME]                   W  onServiceDisconnected (crash or killed by oom): pid=29786 bindings:W  S
2024-11-06 11:21:18.671 29632-29632 chromium                [APP_NAME]                   E  [ERROR:aw_browser_terminator.cc(165)] Renderer process (29786) crash detected (code -1).

Could just be a side effect of the activity closing.

@jdevuono54
Copy link
Author

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.

@breautek
Copy link
Contributor

breautek commented Nov 7, 2024

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 Don't Keep Activities option which will skip whatever logic Android has and always kill the activity when the OS switches to another activity. In android, activity basically refers to an application.

I glanced through the logs and I see:

{
      "header": {
        "logLevel": "DEBUG",
        "pid": 17356,
        "tid": 17356,
        "applicationId": "com.xxx.xxx",
        "processName": "com.xxx.xxx",
        "tag": "CordovaActivity",
        "timestamp": {
          "seconds": 1730989421,
          "nanos": 918000000
        }
      },
      "message": "Stopped the activity."
    },

Note the timestamp: 1730989421

Few seconds later:

{
      "header": {
        "logLevel": "ERROR",
        "pid": 17356,
        "tid": 17356,
        "applicationId": "com.xxx.xxx",
        "processName": "com.xxx.xxx",
        "tag": "WebviewCrashesHandler",
        "timestamp": {
          "seconds": 1730989427,
          "nanos": 360000000
        }
      },
      "message": "La Webview a été tuée par le système"
    },

We see this, but this is to be expected since the activity is stopped and/or stopping.

Fast forward a bit:

{
      "header": {
        "logLevel": "DEBUG",
        "pid": 17356,
        "tid": 17530,
        "applicationId": "com.xxx.xxx",
        "processName": "com.xxx.xxx",
        "tag": "SERVER",
        "timestamp": {
          "seconds": 1730989427,
          "nanos": 477000000
        }
      },
      "message": "Handling local request: https://kwap/index.html#/home"
    },

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 resume event should have the camera result stored in the resume event.

window.document.addEventListener('resume', (e) => {
    console.log(e.pendingResult);
});

Again this flow can be tested when using the "Don't Keep Activities" developer option in the Android developer settings

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants