[camera] Adding check for null before creating capture session. #2965
Conversation
|
This pull request resolve my problem! Thanks! |
|
Good to hear Renan! @bparrishMines there is probably a nicer solution somewhere that solves the underlying issue, but how about we merge this CL for now as it fixes the symptoms? |
|
Friendly bump for @bparrishMines :) |
Occasionally leads to NullPointerException (potentially due to some race condition, hard to reproduce deterministically). Example stack trace: E/AndroidRuntime( 5679): java.lang.NullPointerException: Attempt to invoke virtual method 'android.view.Surface android.media.ImageReader.getSurface()' on a null object reference E/AndroidRuntime( 5679): at io.flutter.plugins.camera.Camera.startPreview(Camera.java:424) E/AndroidRuntime( 5679): at io.flutter.plugins.camera.Camera$2.onOpened(Camera.java:160) E/AndroidRuntime( 5679): at android.hardware.camera2.impl.CameraDeviceImpl$1.run(CameraDeviceImpl.java:145) E/AndroidRuntime( 5679): at android.os.Handler.handleCallback(Handler.java:883) E/AndroidRuntime( 5679): at android.os.Handler.dispatchMessage(Handler.java:100) E/AndroidRuntime( 5679): at android.os.Looper.loop(Looper.java:214) E/AndroidRuntime( 5679): at android.app.ActivityThread.main(ActivityThread.java:7356) E/AndroidRuntime( 5679): at java.lang.reflect.Method.invoke(Native Method) E/AndroidRuntime( 5679): at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492) E/AndroidRuntime( 5679): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
b4cbc18 to
322d664
Compare
|
Rebased again. |
| if (pictureImageReader != null) { | ||
| createCaptureSession(CameraDevice.TEMPLATE_PREVIEW, pictureImageReader.getSurface()); | ||
| } |
There was a problem hiding this comment.
nit: you could invert the if statement to reduce nesting and would make it a bit easier to expand the method:
| if (pictureImageReader != null) { | |
| createCaptureSession(CameraDevice.TEMPLATE_PREVIEW, pictureImageReader.getSurface()); | |
| } | |
| if (pictureImageReader == null) { | |
| return; | |
| } | |
| createCaptureSession(CameraDevice.TEMPLATE_PREVIEW, pictureImageReader.getSurface()); |
There was a problem hiding this comment.
Looking further into this issue, it would be good to know why pictureImageReader is null at this point and if that is valid (as @tvolkert also mentioned in his comments on PR #2871 ).
If the pictureImageReader should not be null when startPreview is called, this code will hide a mistake that is somewhere else in the code. I will start looking into this.
There was a problem hiding this comment.
Thanks Maurits for looking into this! I agree that this is only a workaround for a symptom, but not a proper fix. Do you have a hunch where the real problem could lie?
There was a problem hiding this comment.
Hi @panmari, we (me and a colleague) have been looking into this issue and can't quite reproduce it as of yet. We do have 2 theories at the moment:
- Since version 0.5.0 developers are responsible for handling application lifecycle events that might affect the plugin (see also this comment mentioned by @kevin-lot). If these events are not handled correctly it might cause the issue where the permission system moves the app to the background and not reinitialize the camera plugin correctly (leaving it in an invalid state);
- We could did get the same error when (using the example app) very rapidly switching between the front and back facing cameras. We noticed that in these cases the
onOpenedcallback would be called when thedisposemethod has already been run (race condition).
I am currently discussing on how we should approach these problems.
|
Abandoning in favor of #3127 |
Description
Occasionally leads to NullPointerException (potentially due to some race
condition, hard to reproduce deterministically). This patch makes the error go away. I have an app in prod that has 0 occurences of this behavior after the patch. Example stack trace:
Related Issues
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]). This will ensure a smooth and quick review process.///).flutter analyze) does not report any problems on my PR.Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?