You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Dan Polivy <da...@cellartracker.com> on 2015/06/02 21:05:52 UTC
Android plugin crash on resume when activity destroyed
On Android, when using plugins that launch other intents, e.g. the Camera plugin, I'm now seeing reliable crashes when the cordova activity is resumed - if it was "destroyed" when the intent launched. The reliable way to reproduce this is to enable the "Don't keep activities" setting in Android's Developer options. Based on the Google Play crash reports, this just started when we updated our app to use the new cordova-android@4.0.0<ma...@4.0.0> runtime.
In the Camera plugin, the issue is that the CameraLauncher.processResultFromCamera method uses an instance variable, imageUri, which is set prior to launching the intent, but null when the activity is resumed. Presumably, this is because the plugin isn't aware that it needs to save state? Here's the full stack trace:
java.lang.RuntimeException: Unable to resume activity {<app>}: java.lang.RuntimeException: Failure delivering result ResultInfo{who=null, request=34, result=-1, data=null} to activity {<app>}: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String android.net.Uri.toString()' on a null object reference
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3349)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3380)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2731)
at android.app.ActivityThread.access$900(ActivityThread.java:172)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1421)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:145)
at android.app.ActivityThread.main(ActivityThread.java:5835)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1388)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1183)
Caused by: java.lang.RuntimeException: Failure delivering result ResultInfo{who=null, request=34, result=-1, data=null} to activity {<app>}: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String android.net.Uri.toString()' on a null object reference
at android.app.ActivityThread.deliverResults(ActivityThread.java:3977)
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3335)
... 11 more
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String android.net.Uri.toString()' on a null object reference
at org.apache.cordova.camera.CameraLauncher.processResultFromCamera(CameraLauncher.java:445)
at org.apache.cordova.camera.CameraLauncher.onActivityResult(CameraLauncher.java:674)
at org.apache.cordova.CordovaInterfaceImpl.onActivityResult(CordovaInterfaceImpl.java:120)
at org.apache.cordova.CordovaActivity.onActivityResult(CordovaActivity.java:321)
at android.app.Activity.dispatchActivityResult(Activity.java:6475)
at android.app.ActivityThread.deliverResults(ActivityThread.java:3973)
... 12 more
I've been looking at this for a bit, and am wondering whether this can even be supported with the current plugin architecture. I see that onStart and onStop are now part of the plugin interface, but not onSaveInstanceState/onRestoreInstanceState. It seems like a fairly common pattern for plugins to save the CallbackContext, so this will impact more than just the Camera plugin.
Has any thought gone into supporting this scenario? Is it possible to do with the current plugin interface, or would it need to be extended to add the instance state handlers to allow plugins to preserve necessary state? I'm happy to take a stab at addressing this, but would appreciate insight from the android native devs on the right way to approach this issue. (I haven't yet filed a JIRA issue on this, but will shortly.)
Thanks,
Dan
Re: Android plugin crash on resume when activity destroyed
Posted by Jesse <pu...@gmail.com>.
I'm off for a week after tomorrow, so 2 weeks?
I'll try to get a discuss thread up tomorrow.
@purplecabbage
risingj.com
On Thu, Jun 4, 2015 at 3:00 PM, Serge Huijben <s....@gmail.com> wrote:
> Sounds great Jesse, it would be awesome to have some context awareness in a
> startup event.
> any idea when you could have this ready?
>
> - Serge
>
> Op do 4 jun. 2015 om 22:52 schreef Jesse <pu...@gmail.com>:
>
> > Yes, I am working on a unified solution, which is to include a
> > pre-deviceready event which contains launch context data. This
> would/could
> > include being launched from an intent, or a url:protocol that you have
> > registered, a local notification, a push notification, launch from a
> > secondary tile, ....
> >
> > Typically an app that needs to maintain state should do it whenever state
> > changes. pause/resume events can be used as well, but there is no
> specific
> > event for going from paused->destroyed other than possibly being able to
> > use window.onunload | addEventListener('unload'..
> >
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
> > On Thu, Jun 4, 2015 at 1:04 PM, Dan Polivy <da...@cellartracker.com>
> wrote:
> >
> > > Is there any notification to the app via JS that the activity is being
> > > destroyed, e.g. to allow the app to save state?
> > >
> > > FWIW, I think any plugin that invokes another intent that returns data
> is
> > > potentially vulnerable to this issue -- e.g. barcode scanner being
> > another
> > > one (I have a few real world crashes on this, too -- but not as many as
> > for
> > > Camera). So a more general purpose solution might be appropriate if
> > > possible.
> > >
> > > Dan
> > >
> > > -----Original Message-----
> > > From: Serge Huijben [mailto:s.huijben@gmail.com]
> > > Sent: Wednesday, June 03, 2015 11:39 PM
> > > To: dev@cordova.apache.org
> > > Subject: Re: Android plugin crash on resume when activity destroyed
> > >
> > > Joe, it failing on Travis was not caused by the code in the
> pullrequest.
> > > I just changed one word in the readme.md and committed that to have
> > Travis
> > > build it again and now it's all good.
> > >
> > > - Serge
> > >
> > > Op do 4 jun. 2015 om 07:54 schreef Serge Huijben <s.huijben@gmail.com
> >:
> > >
> > > > I must say that restoring state in the webview has not been a problem
> > for
> > > > me. admittedly our app is only for Android 4.1 (sdk 16) and higher.
> > > > In our app we save state all the time using localstorage, and I do
> know
> > > > exaxtly where the user was at --> he was taking a picture or
> selecting
> > > one
> > > > from the gallery
> > > > that leaves me with only one possible view to deliver to the user.
> > > > I just call checkForSavedResult on the camera plugin in onDeviceReady
> > > > using a promise and if it returns a value I take the user to that
> view.
> > > > localstorage is still intact so the user is non the wiser, maybe
> only a
> > > bit
> > > > confused as to why he just saw the splashscreen. if the returnvalue
> is
> > an
> > > > empty string I take the user to the "welcome" view
> > > >
> > > > This method could be generalised but as Joe pointed out, there's
> little
> > > > chance of this occurring in plugins other than the camera plugin.
> > > >
> > > > - Serge
> > > >
> > > >
> > > > Op wo 3 jun. 2015 om 23:31 schreef Dan Polivy <dan@cellartracker.com
> >:
> > > >
> > > >> Interesting, thanks for the history, Joe and Serge.
> > > >>
> > > >> I do probably agree with you, Joe, that this won't work well as
> it'll
> > be
> > > >> hard to restore the DOM to the correct state. I can say that for my
> > app,
> > > >> it's pretty unlikely to get exactly back to where you started. In
> > prior
> > > >> versions of Cordova (pre-4.0), I think that instead of a crash, the
> > user
> > > >> experience was the app just appeared to restart itself.
> > > >>
> > > >> At the very least, is there any possibility of better handling this
> > > >> scenario at a general level so it doesn't lead to a crash? I guess a
> > > >> targeted fix for the Camera plugin, to perhaps detect this and throw
> > an
> > > >> error dialog, might be a start. I've also seen this with the barcode
> > > >> scanner plugin (which uses the camera). I don't know the policy on
> > > >> introducing localized strings in the core platform components, but
> if
> > > >> there's a way to handle that, it seems like showing the user a
> > (native)
> > > >> notification that it failed would be appropriate.
> > > >>
> > > >> It may also be prudent to update the plugin development guide to
> > discuss
> > > >> this issue and how to prevent crashes from referencing uninitialized
> > > >> instance variables in the intent callback.
> > > >>
> > > >> I may also play with Serge's solution and see if it is viable, and
> > will
> > > >> report back what I find.
> > > >>
> > > >> Dan
> > > >>
> > > >> -----Original Message-----
> > > >> From: Joe Bowser [mailto:bowserj@gmail.com]
> > > >> Sent: Wednesday, June 03, 2015 11:44 AM
> > > >> To: dev@cordova.apache.org
> > > >> Subject: Re: Android plugin crash on resume when activity destroyed
> > > >>
> > > >> This has been a problem since we started, and there's no solution to
> > it
> > > >> because there's no reliable way to restore state on a WebView. We
> > have
> > > >> tried in the past, and failed miserably. I'm extremely skeptical
> that
> > > >> this
> > > >> would even work, since this apparently failed Travis. That said, if
> > it
> > > >> does, every intent would have to manage their own state, and even
> when
> > > the
> > > >> plugin is loaded, we still don't know where in the app the user
> would
> > be
> > > >> at, so returning a photo to a part of the DOM that doesn't even
> exist
> > > >> would
> > > >> have JS errors.
> > > >>
> > > >> Of course, this only happens when you're using a LOT of memory, like
> > > what
> > > >> Cameras tend to do, and other Intents, like for example, requesting
> > > >> permission to use a Tango Service on a Project Tango plugin, (
> > > >> https://github.com/infil00p/PhoneGapTango) or other third party
> > plugins
> > > >> wouldn't run into the same problems.
> > > >>
> > > >> This is a problem with the Android architecture, and many native
> apps
> > > have
> > > >> run into similar problems. I don't think there's a solution for
> this
> > in
> > > >> Cordova, and we have definitely tried.
> > > >>
> > > >> On Wed, Jun 3, 2015 at 9:46 AM Mefire O. <om...@microsoft.com>
> > > wrote:
> > > >>
> > > >> > Interesting fix, Serge. A question comes to mind:
> > > >> > - Since it seems like this issue affects all android plugins that
> > call
> > > >> > other intents, won't we have to do this for all of them? Is there
> a
> > > way
> > > >> we
> > > >> > can leverage your PR and maybe come up with a general solution ?
> > Maybe
> > > >> fit
> > > >> > the boilerplate code (state saving/restoring) somewhere all
> android
> > > >> plugins
> > > >> > can inherit ?
> > > >> >
> > > >> > On Jun 3, 2015 3:54 AM, Serge Huijben <s....@gmail.com>
> wrote:
> > > >> > what I did to solve this is add a check for callbackcontext, If
> that
> > > is
> > > >> > null save the incoming parameters.
> > > >> > if (this.callbackContext == null) {
> > > >> > this.savedRequestCode = requestCode;
> > > >> > this.savedResultCode = resultCode;
> > > >> > this.savedIntent = intent;
> > > >> > } else {
> > > >> > // procede as planned
> > > >> >
> > > >> > This is what happens after the activity has been killed by the
> > system
> > > >> while
> > > >> > you are in the camera Intent.
> > > >> > Once you take or select your picture the mainactivity is restarted
> > and
> > > >> with
> > > >> > it all the plugins, after which onActivityResult is fired.
> > > >> >
> > > >> > the code above saves the incoming parameters so they can be used
> > > later.
> > > >> > To do this I also added a new method, checkForSavedResults,
> > specially
> > > >> for
> > > >> > Android, you call this method in your onDeviceReady javascript
> > method
> > > >> that
> > > >> > will fire once the activity is restarted, and this will give you
> the
> > > >> > previously taken or selected picture.
> > > >> >
> > > >> > I put this in a pullrequest
> > > >> > https://github.com/apache/cordova-plugin-camera/pull/97
> > > >> > It solves Issue CB-8804
> > https://issues.apache.org/jira/browse/CB-8804
> > > >> >
> > > >> > hope this helps,
> > > >> >
> > > >> > Serge
> > > >> >
> > > >> >
> > > >> > Op di 2 jun. 2015 om 21:06 schreef Dan Polivy <
> > dan@cellartracker.com
> > > >:
> > > >> >
> > > >> > > On Android, when using plugins that launch other intents, e.g.
> the
> > > >> Camera
> > > >> > > plugin, I'm now seeing reliable crashes when the cordova
> activity
> > is
> > > >> > > resumed - if it was "destroyed" when the intent launched. The
> > > reliable
> > > >> > way
> > > >> > > to reproduce this is to enable the "Don't keep activities"
> setting
> > > in
> > > >> > > Android's Developer options. Based on the Google Play crash
> > reports,
> > > >> this
> > > >> > > just started when we updated our app to use the new
> > > >> cordova-android@4.0.0
> > > >> > > <ma...@4.0.0> runtime.
> > > >> > >
> > > >> > > In the Camera plugin, the issue is that the
> > > >> > > CameraLauncher.processResultFromCamera method uses an instance
> > > >> variable,
> > > >> > > imageUri, which is set prior to launching the intent, but null
> > when
> > > >> the
> > > >> > > activity is resumed. Presumably, this is because the plugin
> isn't
> > > >> aware
> > > >> > > that it needs to save state? Here's the full stack trace:
> > > >> > >
> > > >> > > java.lang.RuntimeException: Unable to resume activity {<app>}:
> > > >> > > java.lang.RuntimeException: Failure delivering result
> > > >> > ResultInfo{who=null,
> > > >> > > request=34, result=-1, data=null} to activity {<app>}:
> > > >> > > java.lang.NullPointerException: Attempt to invoke virtual method
> > > >> > > 'java.lang.String android.net.Uri.toString()' on a null object
> > > >> reference
> > > >> > > at
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3349)
> > > >> > > at
> > > >> > >
> > > >>
> > >
> android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3380)
> > > >> > > at
> > > >> > >
> > > >>
> > >
> android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2731)
> > > >> > > at
> android.app.ActivityThread.access$900(ActivityThread.java:172)
> > > >> > > at
> > > >> android.app.ActivityThread$H.handleMessage(ActivityThread.java:1421)
> > > >> > > at android.os.Handler.dispatchMessage(Handler.java:102)
> > > >> > > at android.os.Looper.loop(Looper.java:145)
> > > >> > > at android.app.ActivityThread.main(ActivityThread.java:5835)
> > > >> > > at java.lang.reflect.Method.invoke(Native Method)
> > > >> > > at java.lang.reflect.Method.invoke(Method.java:372)
> > > >> > > at
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1388)
> > > >> > > at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1183)
> > > >> > > Caused by: java.lang.RuntimeException: Failure delivering result
> > > >> > > ResultInfo{who=null, request=34, result=-1, data=null} to
> activity
> > > >> > {<app>}:
> > > >> > > java.lang.NullPointerException: Attempt to invoke virtual method
> > > >> > > 'java.lang.String android.net.Uri.toString()' on a null object
> > > >> reference
> > > >> > > at
> > > android.app.ActivityThread.deliverResults(ActivityThread.java:3977)
> > > >> > > at
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3335)
> > > >> > > ... 11 more
> > > >> > > Caused by: java.lang.NullPointerException: Attempt to invoke
> > virtual
> > > >> > > method 'java.lang.String android.net.Uri.toString()' on a null
> > > object
> > > >> > > reference
> > > >> > > at
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> org.apache.cordova.camera.CameraLauncher.processResultFromCamera(CameraLauncher.java:445)
> > > >> > > at
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> org.apache.cordova.camera.CameraLauncher.onActivityResult(CameraLauncher.java:674)
> > > >> > > at
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> org.apache.cordova.CordovaInterfaceImpl.onActivityResult(CordovaInterfaceImpl.java:120)
> > > >> > > at
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> org.apache.cordova.CordovaActivity.onActivityResult(CordovaActivity.java:321)
> > > >> > > at
> android.app.Activity.dispatchActivityResult(Activity.java:6475)
> > > >> > > at
> > > android.app.ActivityThread.deliverResults(ActivityThread.java:3973)
> > > >> > > ... 12 more
> > > >> > >
> > > >> > > I've been looking at this for a bit, and am wondering whether
> this
> > > can
> > > >> > > even be supported with the current plugin architecture. I see
> that
> > > >> > onStart
> > > >> > > and onStop are now part of the plugin interface, but not
> > > >> > > onSaveInstanceState/onRestoreInstanceState. It seems like a
> fairly
> > > >> common
> > > >> > > pattern for plugins to save the CallbackContext, so this will
> > impact
> > > >> more
> > > >> > > than just the Camera plugin.
> > > >> > >
> > > >> > > Has any thought gone into supporting this scenario? Is it
> possible
> > > to
> > > >> do
> > > >> > > with the current plugin interface, or would it need to be
> extended
> > > to
> > > >> add
> > > >> > > the instance state handlers to allow plugins to preserve
> necessary
> > > >> state?
> > > >> > > I'm happy to take a stab at addressing this, but would
> appreciate
> > > >> insight
> > > >> > > from the android native devs on the right way to approach this
> > > issue.
> > > >> (I
> > > >> > > haven't yet filed a JIRA issue on this, but will shortly.)
> > > >> > >
> > > >> > > Thanks,
> > > >> > > Dan
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > >>
> > > >
> > >
> >
>
Re: Android plugin crash on resume when activity destroyed
Posted by Serge Huijben <s....@gmail.com>.
Sounds great Jesse, it would be awesome to have some context awareness in a
startup event.
any idea when you could have this ready?
- Serge
Op do 4 jun. 2015 om 22:52 schreef Jesse <pu...@gmail.com>:
> Yes, I am working on a unified solution, which is to include a
> pre-deviceready event which contains launch context data. This would/could
> include being launched from an intent, or a url:protocol that you have
> registered, a local notification, a push notification, launch from a
> secondary tile, ....
>
> Typically an app that needs to maintain state should do it whenever state
> changes. pause/resume events can be used as well, but there is no specific
> event for going from paused->destroyed other than possibly being able to
> use window.onunload | addEventListener('unload'..
>
>
>
>
> @purplecabbage
> risingj.com
>
> On Thu, Jun 4, 2015 at 1:04 PM, Dan Polivy <da...@cellartracker.com> wrote:
>
> > Is there any notification to the app via JS that the activity is being
> > destroyed, e.g. to allow the app to save state?
> >
> > FWIW, I think any plugin that invokes another intent that returns data is
> > potentially vulnerable to this issue -- e.g. barcode scanner being
> another
> > one (I have a few real world crashes on this, too -- but not as many as
> for
> > Camera). So a more general purpose solution might be appropriate if
> > possible.
> >
> > Dan
> >
> > -----Original Message-----
> > From: Serge Huijben [mailto:s.huijben@gmail.com]
> > Sent: Wednesday, June 03, 2015 11:39 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Android plugin crash on resume when activity destroyed
> >
> > Joe, it failing on Travis was not caused by the code in the pullrequest.
> > I just changed one word in the readme.md and committed that to have
> Travis
> > build it again and now it's all good.
> >
> > - Serge
> >
> > Op do 4 jun. 2015 om 07:54 schreef Serge Huijben <s....@gmail.com>:
> >
> > > I must say that restoring state in the webview has not been a problem
> for
> > > me. admittedly our app is only for Android 4.1 (sdk 16) and higher.
> > > In our app we save state all the time using localstorage, and I do know
> > > exaxtly where the user was at --> he was taking a picture or selecting
> > one
> > > from the gallery
> > > that leaves me with only one possible view to deliver to the user.
> > > I just call checkForSavedResult on the camera plugin in onDeviceReady
> > > using a promise and if it returns a value I take the user to that view.
> > > localstorage is still intact so the user is non the wiser, maybe only a
> > bit
> > > confused as to why he just saw the splashscreen. if the returnvalue is
> an
> > > empty string I take the user to the "welcome" view
> > >
> > > This method could be generalised but as Joe pointed out, there's little
> > > chance of this occurring in plugins other than the camera plugin.
> > >
> > > - Serge
> > >
> > >
> > > Op wo 3 jun. 2015 om 23:31 schreef Dan Polivy <da...@cellartracker.com>:
> > >
> > >> Interesting, thanks for the history, Joe and Serge.
> > >>
> > >> I do probably agree with you, Joe, that this won't work well as it'll
> be
> > >> hard to restore the DOM to the correct state. I can say that for my
> app,
> > >> it's pretty unlikely to get exactly back to where you started. In
> prior
> > >> versions of Cordova (pre-4.0), I think that instead of a crash, the
> user
> > >> experience was the app just appeared to restart itself.
> > >>
> > >> At the very least, is there any possibility of better handling this
> > >> scenario at a general level so it doesn't lead to a crash? I guess a
> > >> targeted fix for the Camera plugin, to perhaps detect this and throw
> an
> > >> error dialog, might be a start. I've also seen this with the barcode
> > >> scanner plugin (which uses the camera). I don't know the policy on
> > >> introducing localized strings in the core platform components, but if
> > >> there's a way to handle that, it seems like showing the user a
> (native)
> > >> notification that it failed would be appropriate.
> > >>
> > >> It may also be prudent to update the plugin development guide to
> discuss
> > >> this issue and how to prevent crashes from referencing uninitialized
> > >> instance variables in the intent callback.
> > >>
> > >> I may also play with Serge's solution and see if it is viable, and
> will
> > >> report back what I find.
> > >>
> > >> Dan
> > >>
> > >> -----Original Message-----
> > >> From: Joe Bowser [mailto:bowserj@gmail.com]
> > >> Sent: Wednesday, June 03, 2015 11:44 AM
> > >> To: dev@cordova.apache.org
> > >> Subject: Re: Android plugin crash on resume when activity destroyed
> > >>
> > >> This has been a problem since we started, and there's no solution to
> it
> > >> because there's no reliable way to restore state on a WebView. We
> have
> > >> tried in the past, and failed miserably. I'm extremely skeptical that
> > >> this
> > >> would even work, since this apparently failed Travis. That said, if
> it
> > >> does, every intent would have to manage their own state, and even when
> > the
> > >> plugin is loaded, we still don't know where in the app the user would
> be
> > >> at, so returning a photo to a part of the DOM that doesn't even exist
> > >> would
> > >> have JS errors.
> > >>
> > >> Of course, this only happens when you're using a LOT of memory, like
> > what
> > >> Cameras tend to do, and other Intents, like for example, requesting
> > >> permission to use a Tango Service on a Project Tango plugin, (
> > >> https://github.com/infil00p/PhoneGapTango) or other third party
> plugins
> > >> wouldn't run into the same problems.
> > >>
> > >> This is a problem with the Android architecture, and many native apps
> > have
> > >> run into similar problems. I don't think there's a solution for this
> in
> > >> Cordova, and we have definitely tried.
> > >>
> > >> On Wed, Jun 3, 2015 at 9:46 AM Mefire O. <om...@microsoft.com>
> > wrote:
> > >>
> > >> > Interesting fix, Serge. A question comes to mind:
> > >> > - Since it seems like this issue affects all android plugins that
> call
> > >> > other intents, won't we have to do this for all of them? Is there a
> > way
> > >> we
> > >> > can leverage your PR and maybe come up with a general solution ?
> Maybe
> > >> fit
> > >> > the boilerplate code (state saving/restoring) somewhere all android
> > >> plugins
> > >> > can inherit ?
> > >> >
> > >> > On Jun 3, 2015 3:54 AM, Serge Huijben <s....@gmail.com> wrote:
> > >> > what I did to solve this is add a check for callbackcontext, If that
> > is
> > >> > null save the incoming parameters.
> > >> > if (this.callbackContext == null) {
> > >> > this.savedRequestCode = requestCode;
> > >> > this.savedResultCode = resultCode;
> > >> > this.savedIntent = intent;
> > >> > } else {
> > >> > // procede as planned
> > >> >
> > >> > This is what happens after the activity has been killed by the
> system
> > >> while
> > >> > you are in the camera Intent.
> > >> > Once you take or select your picture the mainactivity is restarted
> and
> > >> with
> > >> > it all the plugins, after which onActivityResult is fired.
> > >> >
> > >> > the code above saves the incoming parameters so they can be used
> > later.
> > >> > To do this I also added a new method, checkForSavedResults,
> specially
> > >> for
> > >> > Android, you call this method in your onDeviceReady javascript
> method
> > >> that
> > >> > will fire once the activity is restarted, and this will give you the
> > >> > previously taken or selected picture.
> > >> >
> > >> > I put this in a pullrequest
> > >> > https://github.com/apache/cordova-plugin-camera/pull/97
> > >> > It solves Issue CB-8804
> https://issues.apache.org/jira/browse/CB-8804
> > >> >
> > >> > hope this helps,
> > >> >
> > >> > Serge
> > >> >
> > >> >
> > >> > Op di 2 jun. 2015 om 21:06 schreef Dan Polivy <
> dan@cellartracker.com
> > >:
> > >> >
> > >> > > On Android, when using plugins that launch other intents, e.g. the
> > >> Camera
> > >> > > plugin, I'm now seeing reliable crashes when the cordova activity
> is
> > >> > > resumed - if it was "destroyed" when the intent launched. The
> > reliable
> > >> > way
> > >> > > to reproduce this is to enable the "Don't keep activities" setting
> > in
> > >> > > Android's Developer options. Based on the Google Play crash
> reports,
> > >> this
> > >> > > just started when we updated our app to use the new
> > >> cordova-android@4.0.0
> > >> > > <ma...@4.0.0> runtime.
> > >> > >
> > >> > > In the Camera plugin, the issue is that the
> > >> > > CameraLauncher.processResultFromCamera method uses an instance
> > >> variable,
> > >> > > imageUri, which is set prior to launching the intent, but null
> when
> > >> the
> > >> > > activity is resumed. Presumably, this is because the plugin isn't
> > >> aware
> > >> > > that it needs to save state? Here's the full stack trace:
> > >> > >
> > >> > > java.lang.RuntimeException: Unable to resume activity {<app>}:
> > >> > > java.lang.RuntimeException: Failure delivering result
> > >> > ResultInfo{who=null,
> > >> > > request=34, result=-1, data=null} to activity {<app>}:
> > >> > > java.lang.NullPointerException: Attempt to invoke virtual method
> > >> > > 'java.lang.String android.net.Uri.toString()' on a null object
> > >> reference
> > >> > > at
> > >> > >
> > >> >
> > >>
> >
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3349)
> > >> > > at
> > >> > >
> > >>
> > android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3380)
> > >> > > at
> > >> > >
> > >>
> > android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2731)
> > >> > > at android.app.ActivityThread.access$900(ActivityThread.java:172)
> > >> > > at
> > >> android.app.ActivityThread$H.handleMessage(ActivityThread.java:1421)
> > >> > > at android.os.Handler.dispatchMessage(Handler.java:102)
> > >> > > at android.os.Looper.loop(Looper.java:145)
> > >> > > at android.app.ActivityThread.main(ActivityThread.java:5835)
> > >> > > at java.lang.reflect.Method.invoke(Native Method)
> > >> > > at java.lang.reflect.Method.invoke(Method.java:372)
> > >> > > at
> > >> > >
> > >> >
> > >>
> >
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1388)
> > >> > > at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1183)
> > >> > > Caused by: java.lang.RuntimeException: Failure delivering result
> > >> > > ResultInfo{who=null, request=34, result=-1, data=null} to activity
> > >> > {<app>}:
> > >> > > java.lang.NullPointerException: Attempt to invoke virtual method
> > >> > > 'java.lang.String android.net.Uri.toString()' on a null object
> > >> reference
> > >> > > at
> > android.app.ActivityThread.deliverResults(ActivityThread.java:3977)
> > >> > > at
> > >> > >
> > >> >
> > >>
> >
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3335)
> > >> > > ... 11 more
> > >> > > Caused by: java.lang.NullPointerException: Attempt to invoke
> virtual
> > >> > > method 'java.lang.String android.net.Uri.toString()' on a null
> > object
> > >> > > reference
> > >> > > at
> > >> > >
> > >> >
> > >>
> >
> org.apache.cordova.camera.CameraLauncher.processResultFromCamera(CameraLauncher.java:445)
> > >> > > at
> > >> > >
> > >> >
> > >>
> >
> org.apache.cordova.camera.CameraLauncher.onActivityResult(CameraLauncher.java:674)
> > >> > > at
> > >> > >
> > >> >
> > >>
> >
> org.apache.cordova.CordovaInterfaceImpl.onActivityResult(CordovaInterfaceImpl.java:120)
> > >> > > at
> > >> > >
> > >> >
> > >>
> >
> org.apache.cordova.CordovaActivity.onActivityResult(CordovaActivity.java:321)
> > >> > > at android.app.Activity.dispatchActivityResult(Activity.java:6475)
> > >> > > at
> > android.app.ActivityThread.deliverResults(ActivityThread.java:3973)
> > >> > > ... 12 more
> > >> > >
> > >> > > I've been looking at this for a bit, and am wondering whether this
> > can
> > >> > > even be supported with the current plugin architecture. I see that
> > >> > onStart
> > >> > > and onStop are now part of the plugin interface, but not
> > >> > > onSaveInstanceState/onRestoreInstanceState. It seems like a fairly
> > >> common
> > >> > > pattern for plugins to save the CallbackContext, so this will
> impact
> > >> more
> > >> > > than just the Camera plugin.
> > >> > >
> > >> > > Has any thought gone into supporting this scenario? Is it possible
> > to
> > >> do
> > >> > > with the current plugin interface, or would it need to be extended
> > to
> > >> add
> > >> > > the instance state handlers to allow plugins to preserve necessary
> > >> state?
> > >> > > I'm happy to take a stab at addressing this, but would appreciate
> > >> insight
> > >> > > from the android native devs on the right way to approach this
> > issue.
> > >> (I
> > >> > > haven't yet filed a JIRA issue on this, but will shortly.)
> > >> > >
> > >> > > Thanks,
> > >> > > Dan
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >
> >
>
Re: Android plugin crash on resume when activity destroyed
Posted by Jesse <pu...@gmail.com>.
Yes, I am working on a unified solution, which is to include a
pre-deviceready event which contains launch context data. This would/could
include being launched from an intent, or a url:protocol that you have
registered, a local notification, a push notification, launch from a
secondary tile, ....
Typically an app that needs to maintain state should do it whenever state
changes. pause/resume events can be used as well, but there is no specific
event for going from paused->destroyed other than possibly being able to
use window.onunload | addEventListener('unload'..
@purplecabbage
risingj.com
On Thu, Jun 4, 2015 at 1:04 PM, Dan Polivy <da...@cellartracker.com> wrote:
> Is there any notification to the app via JS that the activity is being
> destroyed, e.g. to allow the app to save state?
>
> FWIW, I think any plugin that invokes another intent that returns data is
> potentially vulnerable to this issue -- e.g. barcode scanner being another
> one (I have a few real world crashes on this, too -- but not as many as for
> Camera). So a more general purpose solution might be appropriate if
> possible.
>
> Dan
>
> -----Original Message-----
> From: Serge Huijben [mailto:s.huijben@gmail.com]
> Sent: Wednesday, June 03, 2015 11:39 PM
> To: dev@cordova.apache.org
> Subject: Re: Android plugin crash on resume when activity destroyed
>
> Joe, it failing on Travis was not caused by the code in the pullrequest.
> I just changed one word in the readme.md and committed that to have Travis
> build it again and now it's all good.
>
> - Serge
>
> Op do 4 jun. 2015 om 07:54 schreef Serge Huijben <s....@gmail.com>:
>
> > I must say that restoring state in the webview has not been a problem for
> > me. admittedly our app is only for Android 4.1 (sdk 16) and higher.
> > In our app we save state all the time using localstorage, and I do know
> > exaxtly where the user was at --> he was taking a picture or selecting
> one
> > from the gallery
> > that leaves me with only one possible view to deliver to the user.
> > I just call checkForSavedResult on the camera plugin in onDeviceReady
> > using a promise and if it returns a value I take the user to that view.
> > localstorage is still intact so the user is non the wiser, maybe only a
> bit
> > confused as to why he just saw the splashscreen. if the returnvalue is an
> > empty string I take the user to the "welcome" view
> >
> > This method could be generalised but as Joe pointed out, there's little
> > chance of this occurring in plugins other than the camera plugin.
> >
> > - Serge
> >
> >
> > Op wo 3 jun. 2015 om 23:31 schreef Dan Polivy <da...@cellartracker.com>:
> >
> >> Interesting, thanks for the history, Joe and Serge.
> >>
> >> I do probably agree with you, Joe, that this won't work well as it'll be
> >> hard to restore the DOM to the correct state. I can say that for my app,
> >> it's pretty unlikely to get exactly back to where you started. In prior
> >> versions of Cordova (pre-4.0), I think that instead of a crash, the user
> >> experience was the app just appeared to restart itself.
> >>
> >> At the very least, is there any possibility of better handling this
> >> scenario at a general level so it doesn't lead to a crash? I guess a
> >> targeted fix for the Camera plugin, to perhaps detect this and throw an
> >> error dialog, might be a start. I've also seen this with the barcode
> >> scanner plugin (which uses the camera). I don't know the policy on
> >> introducing localized strings in the core platform components, but if
> >> there's a way to handle that, it seems like showing the user a (native)
> >> notification that it failed would be appropriate.
> >>
> >> It may also be prudent to update the plugin development guide to discuss
> >> this issue and how to prevent crashes from referencing uninitialized
> >> instance variables in the intent callback.
> >>
> >> I may also play with Serge's solution and see if it is viable, and will
> >> report back what I find.
> >>
> >> Dan
> >>
> >> -----Original Message-----
> >> From: Joe Bowser [mailto:bowserj@gmail.com]
> >> Sent: Wednesday, June 03, 2015 11:44 AM
> >> To: dev@cordova.apache.org
> >> Subject: Re: Android plugin crash on resume when activity destroyed
> >>
> >> This has been a problem since we started, and there's no solution to it
> >> because there's no reliable way to restore state on a WebView. We have
> >> tried in the past, and failed miserably. I'm extremely skeptical that
> >> this
> >> would even work, since this apparently failed Travis. That said, if it
> >> does, every intent would have to manage their own state, and even when
> the
> >> plugin is loaded, we still don't know where in the app the user would be
> >> at, so returning a photo to a part of the DOM that doesn't even exist
> >> would
> >> have JS errors.
> >>
> >> Of course, this only happens when you're using a LOT of memory, like
> what
> >> Cameras tend to do, and other Intents, like for example, requesting
> >> permission to use a Tango Service on a Project Tango plugin, (
> >> https://github.com/infil00p/PhoneGapTango) or other third party plugins
> >> wouldn't run into the same problems.
> >>
> >> This is a problem with the Android architecture, and many native apps
> have
> >> run into similar problems. I don't think there's a solution for this in
> >> Cordova, and we have definitely tried.
> >>
> >> On Wed, Jun 3, 2015 at 9:46 AM Mefire O. <om...@microsoft.com>
> wrote:
> >>
> >> > Interesting fix, Serge. A question comes to mind:
> >> > - Since it seems like this issue affects all android plugins that call
> >> > other intents, won't we have to do this for all of them? Is there a
> way
> >> we
> >> > can leverage your PR and maybe come up with a general solution ? Maybe
> >> fit
> >> > the boilerplate code (state saving/restoring) somewhere all android
> >> plugins
> >> > can inherit ?
> >> >
> >> > On Jun 3, 2015 3:54 AM, Serge Huijben <s....@gmail.com> wrote:
> >> > what I did to solve this is add a check for callbackcontext, If that
> is
> >> > null save the incoming parameters.
> >> > if (this.callbackContext == null) {
> >> > this.savedRequestCode = requestCode;
> >> > this.savedResultCode = resultCode;
> >> > this.savedIntent = intent;
> >> > } else {
> >> > // procede as planned
> >> >
> >> > This is what happens after the activity has been killed by the system
> >> while
> >> > you are in the camera Intent.
> >> > Once you take or select your picture the mainactivity is restarted and
> >> with
> >> > it all the plugins, after which onActivityResult is fired.
> >> >
> >> > the code above saves the incoming parameters so they can be used
> later.
> >> > To do this I also added a new method, checkForSavedResults, specially
> >> for
> >> > Android, you call this method in your onDeviceReady javascript method
> >> that
> >> > will fire once the activity is restarted, and this will give you the
> >> > previously taken or selected picture.
> >> >
> >> > I put this in a pullrequest
> >> > https://github.com/apache/cordova-plugin-camera/pull/97
> >> > It solves Issue CB-8804 https://issues.apache.org/jira/browse/CB-8804
> >> >
> >> > hope this helps,
> >> >
> >> > Serge
> >> >
> >> >
> >> > Op di 2 jun. 2015 om 21:06 schreef Dan Polivy <dan@cellartracker.com
> >:
> >> >
> >> > > On Android, when using plugins that launch other intents, e.g. the
> >> Camera
> >> > > plugin, I'm now seeing reliable crashes when the cordova activity is
> >> > > resumed - if it was "destroyed" when the intent launched. The
> reliable
> >> > way
> >> > > to reproduce this is to enable the "Don't keep activities" setting
> in
> >> > > Android's Developer options. Based on the Google Play crash reports,
> >> this
> >> > > just started when we updated our app to use the new
> >> cordova-android@4.0.0
> >> > > <ma...@4.0.0> runtime.
> >> > >
> >> > > In the Camera plugin, the issue is that the
> >> > > CameraLauncher.processResultFromCamera method uses an instance
> >> variable,
> >> > > imageUri, which is set prior to launching the intent, but null when
> >> the
> >> > > activity is resumed. Presumably, this is because the plugin isn't
> >> aware
> >> > > that it needs to save state? Here's the full stack trace:
> >> > >
> >> > > java.lang.RuntimeException: Unable to resume activity {<app>}:
> >> > > java.lang.RuntimeException: Failure delivering result
> >> > ResultInfo{who=null,
> >> > > request=34, result=-1, data=null} to activity {<app>}:
> >> > > java.lang.NullPointerException: Attempt to invoke virtual method
> >> > > 'java.lang.String android.net.Uri.toString()' on a null object
> >> reference
> >> > > at
> >> > >
> >> >
> >>
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3349)
> >> > > at
> >> > >
> >>
> android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3380)
> >> > > at
> >> > >
> >>
> android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2731)
> >> > > at android.app.ActivityThread.access$900(ActivityThread.java:172)
> >> > > at
> >> android.app.ActivityThread$H.handleMessage(ActivityThread.java:1421)
> >> > > at android.os.Handler.dispatchMessage(Handler.java:102)
> >> > > at android.os.Looper.loop(Looper.java:145)
> >> > > at android.app.ActivityThread.main(ActivityThread.java:5835)
> >> > > at java.lang.reflect.Method.invoke(Native Method)
> >> > > at java.lang.reflect.Method.invoke(Method.java:372)
> >> > > at
> >> > >
> >> >
> >>
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1388)
> >> > > at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1183)
> >> > > Caused by: java.lang.RuntimeException: Failure delivering result
> >> > > ResultInfo{who=null, request=34, result=-1, data=null} to activity
> >> > {<app>}:
> >> > > java.lang.NullPointerException: Attempt to invoke virtual method
> >> > > 'java.lang.String android.net.Uri.toString()' on a null object
> >> reference
> >> > > at
> android.app.ActivityThread.deliverResults(ActivityThread.java:3977)
> >> > > at
> >> > >
> >> >
> >>
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3335)
> >> > > ... 11 more
> >> > > Caused by: java.lang.NullPointerException: Attempt to invoke virtual
> >> > > method 'java.lang.String android.net.Uri.toString()' on a null
> object
> >> > > reference
> >> > > at
> >> > >
> >> >
> >>
> org.apache.cordova.camera.CameraLauncher.processResultFromCamera(CameraLauncher.java:445)
> >> > > at
> >> > >
> >> >
> >>
> org.apache.cordova.camera.CameraLauncher.onActivityResult(CameraLauncher.java:674)
> >> > > at
> >> > >
> >> >
> >>
> org.apache.cordova.CordovaInterfaceImpl.onActivityResult(CordovaInterfaceImpl.java:120)
> >> > > at
> >> > >
> >> >
> >>
> org.apache.cordova.CordovaActivity.onActivityResult(CordovaActivity.java:321)
> >> > > at android.app.Activity.dispatchActivityResult(Activity.java:6475)
> >> > > at
> android.app.ActivityThread.deliverResults(ActivityThread.java:3973)
> >> > > ... 12 more
> >> > >
> >> > > I've been looking at this for a bit, and am wondering whether this
> can
> >> > > even be supported with the current plugin architecture. I see that
> >> > onStart
> >> > > and onStop are now part of the plugin interface, but not
> >> > > onSaveInstanceState/onRestoreInstanceState. It seems like a fairly
> >> common
> >> > > pattern for plugins to save the CallbackContext, so this will impact
> >> more
> >> > > than just the Camera plugin.
> >> > >
> >> > > Has any thought gone into supporting this scenario? Is it possible
> to
> >> do
> >> > > with the current plugin interface, or would it need to be extended
> to
> >> add
> >> > > the instance state handlers to allow plugins to preserve necessary
> >> state?
> >> > > I'm happy to take a stab at addressing this, but would appreciate
> >> insight
> >> > > from the android native devs on the right way to approach this
> issue.
> >> (I
> >> > > haven't yet filed a JIRA issue on this, but will shortly.)
> >> > >
> >> > > Thanks,
> >> > > Dan
> >> > >
> >> > >
> >> > >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >
>
RE: Android plugin crash on resume when activity destroyed
Posted by Dan Polivy <da...@cellartracker.com>.
Is there any notification to the app via JS that the activity is being destroyed, e.g. to allow the app to save state?
FWIW, I think any plugin that invokes another intent that returns data is potentially vulnerable to this issue -- e.g. barcode scanner being another one (I have a few real world crashes on this, too -- but not as many as for Camera). So a more general purpose solution might be appropriate if possible.
Dan
-----Original Message-----
From: Serge Huijben [mailto:s.huijben@gmail.com]
Sent: Wednesday, June 03, 2015 11:39 PM
To: dev@cordova.apache.org
Subject: Re: Android plugin crash on resume when activity destroyed
Joe, it failing on Travis was not caused by the code in the pullrequest.
I just changed one word in the readme.md and committed that to have Travis
build it again and now it's all good.
- Serge
Op do 4 jun. 2015 om 07:54 schreef Serge Huijben <s....@gmail.com>:
> I must say that restoring state in the webview has not been a problem for
> me. admittedly our app is only for Android 4.1 (sdk 16) and higher.
> In our app we save state all the time using localstorage, and I do know
> exaxtly where the user was at --> he was taking a picture or selecting one
> from the gallery
> that leaves me with only one possible view to deliver to the user.
> I just call checkForSavedResult on the camera plugin in onDeviceReady
> using a promise and if it returns a value I take the user to that view.
> localstorage is still intact so the user is non the wiser, maybe only a bit
> confused as to why he just saw the splashscreen. if the returnvalue is an
> empty string I take the user to the "welcome" view
>
> This method could be generalised but as Joe pointed out, there's little
> chance of this occurring in plugins other than the camera plugin.
>
> - Serge
>
>
> Op wo 3 jun. 2015 om 23:31 schreef Dan Polivy <da...@cellartracker.com>:
>
>> Interesting, thanks for the history, Joe and Serge.
>>
>> I do probably agree with you, Joe, that this won't work well as it'll be
>> hard to restore the DOM to the correct state. I can say that for my app,
>> it's pretty unlikely to get exactly back to where you started. In prior
>> versions of Cordova (pre-4.0), I think that instead of a crash, the user
>> experience was the app just appeared to restart itself.
>>
>> At the very least, is there any possibility of better handling this
>> scenario at a general level so it doesn't lead to a crash? I guess a
>> targeted fix for the Camera plugin, to perhaps detect this and throw an
>> error dialog, might be a start. I've also seen this with the barcode
>> scanner plugin (which uses the camera). I don't know the policy on
>> introducing localized strings in the core platform components, but if
>> there's a way to handle that, it seems like showing the user a (native)
>> notification that it failed would be appropriate.
>>
>> It may also be prudent to update the plugin development guide to discuss
>> this issue and how to prevent crashes from referencing uninitialized
>> instance variables in the intent callback.
>>
>> I may also play with Serge's solution and see if it is viable, and will
>> report back what I find.
>>
>> Dan
>>
>> -----Original Message-----
>> From: Joe Bowser [mailto:bowserj@gmail.com]
>> Sent: Wednesday, June 03, 2015 11:44 AM
>> To: dev@cordova.apache.org
>> Subject: Re: Android plugin crash on resume when activity destroyed
>>
>> This has been a problem since we started, and there's no solution to it
>> because there's no reliable way to restore state on a WebView. We have
>> tried in the past, and failed miserably. I'm extremely skeptical that
>> this
>> would even work, since this apparently failed Travis. That said, if it
>> does, every intent would have to manage their own state, and even when the
>> plugin is loaded, we still don't know where in the app the user would be
>> at, so returning a photo to a part of the DOM that doesn't even exist
>> would
>> have JS errors.
>>
>> Of course, this only happens when you're using a LOT of memory, like what
>> Cameras tend to do, and other Intents, like for example, requesting
>> permission to use a Tango Service on a Project Tango plugin, (
>> https://github.com/infil00p/PhoneGapTango) or other third party plugins
>> wouldn't run into the same problems.
>>
>> This is a problem with the Android architecture, and many native apps have
>> run into similar problems. I don't think there's a solution for this in
>> Cordova, and we have definitely tried.
>>
>> On Wed, Jun 3, 2015 at 9:46 AM Mefire O. <om...@microsoft.com> wrote:
>>
>> > Interesting fix, Serge. A question comes to mind:
>> > - Since it seems like this issue affects all android plugins that call
>> > other intents, won't we have to do this for all of them? Is there a way
>> we
>> > can leverage your PR and maybe come up with a general solution ? Maybe
>> fit
>> > the boilerplate code (state saving/restoring) somewhere all android
>> plugins
>> > can inherit ?
>> >
>> > On Jun 3, 2015 3:54 AM, Serge Huijben <s....@gmail.com> wrote:
>> > what I did to solve this is add a check for callbackcontext, If that is
>> > null save the incoming parameters.
>> > if (this.callbackContext == null) {
>> > this.savedRequestCode = requestCode;
>> > this.savedResultCode = resultCode;
>> > this.savedIntent = intent;
>> > } else {
>> > // procede as planned
>> >
>> > This is what happens after the activity has been killed by the system
>> while
>> > you are in the camera Intent.
>> > Once you take or select your picture the mainactivity is restarted and
>> with
>> > it all the plugins, after which onActivityResult is fired.
>> >
>> > the code above saves the incoming parameters so they can be used later.
>> > To do this I also added a new method, checkForSavedResults, specially
>> for
>> > Android, you call this method in your onDeviceReady javascript method
>> that
>> > will fire once the activity is restarted, and this will give you the
>> > previously taken or selected picture.
>> >
>> > I put this in a pullrequest
>> > https://github.com/apache/cordova-plugin-camera/pull/97
>> > It solves Issue CB-8804 https://issues.apache.org/jira/browse/CB-8804
>> >
>> > hope this helps,
>> >
>> > Serge
>> >
>> >
>> > Op di 2 jun. 2015 om 21:06 schreef Dan Polivy <da...@cellartracker.com>:
>> >
>> > > On Android, when using plugins that launch other intents, e.g. the
>> Camera
>> > > plugin, I'm now seeing reliable crashes when the cordova activity is
>> > > resumed - if it was "destroyed" when the intent launched. The reliable
>> > way
>> > > to reproduce this is to enable the "Don't keep activities" setting in
>> > > Android's Developer options. Based on the Google Play crash reports,
>> this
>> > > just started when we updated our app to use the new
>> cordova-android@4.0.0
>> > > <ma...@4.0.0> runtime.
>> > >
>> > > In the Camera plugin, the issue is that the
>> > > CameraLauncher.processResultFromCamera method uses an instance
>> variable,
>> > > imageUri, which is set prior to launching the intent, but null when
>> the
>> > > activity is resumed. Presumably, this is because the plugin isn't
>> aware
>> > > that it needs to save state? Here's the full stack trace:
>> > >
>> > > java.lang.RuntimeException: Unable to resume activity {<app>}:
>> > > java.lang.RuntimeException: Failure delivering result
>> > ResultInfo{who=null,
>> > > request=34, result=-1, data=null} to activity {<app>}:
>> > > java.lang.NullPointerException: Attempt to invoke virtual method
>> > > 'java.lang.String android.net.Uri.toString()' on a null object
>> reference
>> > > at
>> > >
>> >
>> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3349)
>> > > at
>> > >
>> android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3380)
>> > > at
>> > >
>> android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2731)
>> > > at android.app.ActivityThread.access$900(ActivityThread.java:172)
>> > > at
>> android.app.ActivityThread$H.handleMessage(ActivityThread.java:1421)
>> > > at android.os.Handler.dispatchMessage(Handler.java:102)
>> > > at android.os.Looper.loop(Looper.java:145)
>> > > at android.app.ActivityThread.main(ActivityThread.java:5835)
>> > > at java.lang.reflect.Method.invoke(Native Method)
>> > > at java.lang.reflect.Method.invoke(Method.java:372)
>> > > at
>> > >
>> >
>> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1388)
>> > > at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1183)
>> > > Caused by: java.lang.RuntimeException: Failure delivering result
>> > > ResultInfo{who=null, request=34, result=-1, data=null} to activity
>> > {<app>}:
>> > > java.lang.NullPointerException: Attempt to invoke virtual method
>> > > 'java.lang.String android.net.Uri.toString()' on a null object
>> reference
>> > > at android.app.ActivityThread.deliverResults(ActivityThread.java:3977)
>> > > at
>> > >
>> >
>> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3335)
>> > > ... 11 more
>> > > Caused by: java.lang.NullPointerException: Attempt to invoke virtual
>> > > method 'java.lang.String android.net.Uri.toString()' on a null object
>> > > reference
>> > > at
>> > >
>> >
>> org.apache.cordova.camera.CameraLauncher.processResultFromCamera(CameraLauncher.java:445)
>> > > at
>> > >
>> >
>> org.apache.cordova.camera.CameraLauncher.onActivityResult(CameraLauncher.java:674)
>> > > at
>> > >
>> >
>> org.apache.cordova.CordovaInterfaceImpl.onActivityResult(CordovaInterfaceImpl.java:120)
>> > > at
>> > >
>> >
>> org.apache.cordova.CordovaActivity.onActivityResult(CordovaActivity.java:321)
>> > > at android.app.Activity.dispatchActivityResult(Activity.java:6475)
>> > > at android.app.ActivityThread.deliverResults(ActivityThread.java:3973)
>> > > ... 12 more
>> > >
>> > > I've been looking at this for a bit, and am wondering whether this can
>> > > even be supported with the current plugin architecture. I see that
>> > onStart
>> > > and onStop are now part of the plugin interface, but not
>> > > onSaveInstanceState/onRestoreInstanceState. It seems like a fairly
>> common
>> > > pattern for plugins to save the CallbackContext, so this will impact
>> more
>> > > than just the Camera plugin.
>> > >
>> > > Has any thought gone into supporting this scenario? Is it possible to
>> do
>> > > with the current plugin interface, or would it need to be extended to
>> add
>> > > the instance state handlers to allow plugins to preserve necessary
>> state?
>> > > I'm happy to take a stab at addressing this, but would appreciate
>> insight
>> > > from the android native devs on the right way to approach this issue.
>> (I
>> > > haven't yet filed a JIRA issue on this, but will shortly.)
>> > >
>> > > Thanks,
>> > > Dan
>> > >
>> > >
>> > >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>
Re: Android plugin crash on resume when activity destroyed
Posted by Serge Huijben <s....@gmail.com>.
Joe, it failing on Travis was not caused by the code in the pullrequest.
I just changed one word in the readme.md and committed that to have Travis
build it again and now it's all good.
- Serge
Op do 4 jun. 2015 om 07:54 schreef Serge Huijben <s....@gmail.com>:
> I must say that restoring state in the webview has not been a problem for
> me. admittedly our app is only for Android 4.1 (sdk 16) and higher.
> In our app we save state all the time using localstorage, and I do know
> exaxtly where the user was at --> he was taking a picture or selecting one
> from the gallery
> that leaves me with only one possible view to deliver to the user.
> I just call checkForSavedResult on the camera plugin in onDeviceReady
> using a promise and if it returns a value I take the user to that view.
> localstorage is still intact so the user is non the wiser, maybe only a bit
> confused as to why he just saw the splashscreen. if the returnvalue is an
> empty string I take the user to the "welcome" view
>
> This method could be generalised but as Joe pointed out, there's little
> chance of this occurring in plugins other than the camera plugin.
>
> - Serge
>
>
> Op wo 3 jun. 2015 om 23:31 schreef Dan Polivy <da...@cellartracker.com>:
>
>> Interesting, thanks for the history, Joe and Serge.
>>
>> I do probably agree with you, Joe, that this won't work well as it'll be
>> hard to restore the DOM to the correct state. I can say that for my app,
>> it's pretty unlikely to get exactly back to where you started. In prior
>> versions of Cordova (pre-4.0), I think that instead of a crash, the user
>> experience was the app just appeared to restart itself.
>>
>> At the very least, is there any possibility of better handling this
>> scenario at a general level so it doesn't lead to a crash? I guess a
>> targeted fix for the Camera plugin, to perhaps detect this and throw an
>> error dialog, might be a start. I've also seen this with the barcode
>> scanner plugin (which uses the camera). I don't know the policy on
>> introducing localized strings in the core platform components, but if
>> there's a way to handle that, it seems like showing the user a (native)
>> notification that it failed would be appropriate.
>>
>> It may also be prudent to update the plugin development guide to discuss
>> this issue and how to prevent crashes from referencing uninitialized
>> instance variables in the intent callback.
>>
>> I may also play with Serge's solution and see if it is viable, and will
>> report back what I find.
>>
>> Dan
>>
>> -----Original Message-----
>> From: Joe Bowser [mailto:bowserj@gmail.com]
>> Sent: Wednesday, June 03, 2015 11:44 AM
>> To: dev@cordova.apache.org
>> Subject: Re: Android plugin crash on resume when activity destroyed
>>
>> This has been a problem since we started, and there's no solution to it
>> because there's no reliable way to restore state on a WebView. We have
>> tried in the past, and failed miserably. I'm extremely skeptical that
>> this
>> would even work, since this apparently failed Travis. That said, if it
>> does, every intent would have to manage their own state, and even when the
>> plugin is loaded, we still don't know where in the app the user would be
>> at, so returning a photo to a part of the DOM that doesn't even exist
>> would
>> have JS errors.
>>
>> Of course, this only happens when you're using a LOT of memory, like what
>> Cameras tend to do, and other Intents, like for example, requesting
>> permission to use a Tango Service on a Project Tango plugin, (
>> https://github.com/infil00p/PhoneGapTango) or other third party plugins
>> wouldn't run into the same problems.
>>
>> This is a problem with the Android architecture, and many native apps have
>> run into similar problems. I don't think there's a solution for this in
>> Cordova, and we have definitely tried.
>>
>> On Wed, Jun 3, 2015 at 9:46 AM Mefire O. <om...@microsoft.com> wrote:
>>
>> > Interesting fix, Serge. A question comes to mind:
>> > - Since it seems like this issue affects all android plugins that call
>> > other intents, won't we have to do this for all of them? Is there a way
>> we
>> > can leverage your PR and maybe come up with a general solution ? Maybe
>> fit
>> > the boilerplate code (state saving/restoring) somewhere all android
>> plugins
>> > can inherit ?
>> >
>> > On Jun 3, 2015 3:54 AM, Serge Huijben <s....@gmail.com> wrote:
>> > what I did to solve this is add a check for callbackcontext, If that is
>> > null save the incoming parameters.
>> > if (this.callbackContext == null) {
>> > this.savedRequestCode = requestCode;
>> > this.savedResultCode = resultCode;
>> > this.savedIntent = intent;
>> > } else {
>> > // procede as planned
>> >
>> > This is what happens after the activity has been killed by the system
>> while
>> > you are in the camera Intent.
>> > Once you take or select your picture the mainactivity is restarted and
>> with
>> > it all the plugins, after which onActivityResult is fired.
>> >
>> > the code above saves the incoming parameters so they can be used later.
>> > To do this I also added a new method, checkForSavedResults, specially
>> for
>> > Android, you call this method in your onDeviceReady javascript method
>> that
>> > will fire once the activity is restarted, and this will give you the
>> > previously taken or selected picture.
>> >
>> > I put this in a pullrequest
>> > https://github.com/apache/cordova-plugin-camera/pull/97
>> > It solves Issue CB-8804 https://issues.apache.org/jira/browse/CB-8804
>> >
>> > hope this helps,
>> >
>> > Serge
>> >
>> >
>> > Op di 2 jun. 2015 om 21:06 schreef Dan Polivy <da...@cellartracker.com>:
>> >
>> > > On Android, when using plugins that launch other intents, e.g. the
>> Camera
>> > > plugin, I'm now seeing reliable crashes when the cordova activity is
>> > > resumed - if it was "destroyed" when the intent launched. The reliable
>> > way
>> > > to reproduce this is to enable the "Don't keep activities" setting in
>> > > Android's Developer options. Based on the Google Play crash reports,
>> this
>> > > just started when we updated our app to use the new
>> cordova-android@4.0.0
>> > > <ma...@4.0.0> runtime.
>> > >
>> > > In the Camera plugin, the issue is that the
>> > > CameraLauncher.processResultFromCamera method uses an instance
>> variable,
>> > > imageUri, which is set prior to launching the intent, but null when
>> the
>> > > activity is resumed. Presumably, this is because the plugin isn't
>> aware
>> > > that it needs to save state? Here's the full stack trace:
>> > >
>> > > java.lang.RuntimeException: Unable to resume activity {<app>}:
>> > > java.lang.RuntimeException: Failure delivering result
>> > ResultInfo{who=null,
>> > > request=34, result=-1, data=null} to activity {<app>}:
>> > > java.lang.NullPointerException: Attempt to invoke virtual method
>> > > 'java.lang.String android.net.Uri.toString()' on a null object
>> reference
>> > > at
>> > >
>> >
>> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3349)
>> > > at
>> > >
>> android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3380)
>> > > at
>> > >
>> android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2731)
>> > > at android.app.ActivityThread.access$900(ActivityThread.java:172)
>> > > at
>> android.app.ActivityThread$H.handleMessage(ActivityThread.java:1421)
>> > > at android.os.Handler.dispatchMessage(Handler.java:102)
>> > > at android.os.Looper.loop(Looper.java:145)
>> > > at android.app.ActivityThread.main(ActivityThread.java:5835)
>> > > at java.lang.reflect.Method.invoke(Native Method)
>> > > at java.lang.reflect.Method.invoke(Method.java:372)
>> > > at
>> > >
>> >
>> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1388)
>> > > at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1183)
>> > > Caused by: java.lang.RuntimeException: Failure delivering result
>> > > ResultInfo{who=null, request=34, result=-1, data=null} to activity
>> > {<app>}:
>> > > java.lang.NullPointerException: Attempt to invoke virtual method
>> > > 'java.lang.String android.net.Uri.toString()' on a null object
>> reference
>> > > at android.app.ActivityThread.deliverResults(ActivityThread.java:3977)
>> > > at
>> > >
>> >
>> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3335)
>> > > ... 11 more
>> > > Caused by: java.lang.NullPointerException: Attempt to invoke virtual
>> > > method 'java.lang.String android.net.Uri.toString()' on a null object
>> > > reference
>> > > at
>> > >
>> >
>> org.apache.cordova.camera.CameraLauncher.processResultFromCamera(CameraLauncher.java:445)
>> > > at
>> > >
>> >
>> org.apache.cordova.camera.CameraLauncher.onActivityResult(CameraLauncher.java:674)
>> > > at
>> > >
>> >
>> org.apache.cordova.CordovaInterfaceImpl.onActivityResult(CordovaInterfaceImpl.java:120)
>> > > at
>> > >
>> >
>> org.apache.cordova.CordovaActivity.onActivityResult(CordovaActivity.java:321)
>> > > at android.app.Activity.dispatchActivityResult(Activity.java:6475)
>> > > at android.app.ActivityThread.deliverResults(ActivityThread.java:3973)
>> > > ... 12 more
>> > >
>> > > I've been looking at this for a bit, and am wondering whether this can
>> > > even be supported with the current plugin architecture. I see that
>> > onStart
>> > > and onStop are now part of the plugin interface, but not
>> > > onSaveInstanceState/onRestoreInstanceState. It seems like a fairly
>> common
>> > > pattern for plugins to save the CallbackContext, so this will impact
>> more
>> > > than just the Camera plugin.
>> > >
>> > > Has any thought gone into supporting this scenario? Is it possible to
>> do
>> > > with the current plugin interface, or would it need to be extended to
>> add
>> > > the instance state handlers to allow plugins to preserve necessary
>> state?
>> > > I'm happy to take a stab at addressing this, but would appreciate
>> insight
>> > > from the android native devs on the right way to approach this issue.
>> (I
>> > > haven't yet filed a JIRA issue on this, but will shortly.)
>> > >
>> > > Thanks,
>> > > Dan
>> > >
>> > >
>> > >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>
Re: Android plugin crash on resume when activity destroyed
Posted by Serge Huijben <s....@gmail.com>.
I must say that restoring state in the webview has not been a problem for
me. admittedly our app is only for Android 4.1 (sdk 16) and higher.
In our app we save state all the time using localstorage, and I do know
exaxtly where the user was at --> he was taking a picture or selecting one
from the gallery
that leaves me with only one possible view to deliver to the user.
I just call checkForSavedResult on the camera plugin in onDeviceReady using
a promise and if it returns a value I take the user to that view.
localstorage is still intact so the user is non the wiser, maybe only a bit
confused as to why he just saw the splashscreen. if the returnvalue is an
empty string I take the user to the "welcome" view
This method could be generalised but as Joe pointed out, there's little
chance of this occurring in plugins other than the camera plugin.
- Serge
Op wo 3 jun. 2015 om 23:31 schreef Dan Polivy <da...@cellartracker.com>:
> Interesting, thanks for the history, Joe and Serge.
>
> I do probably agree with you, Joe, that this won't work well as it'll be
> hard to restore the DOM to the correct state. I can say that for my app,
> it's pretty unlikely to get exactly back to where you started. In prior
> versions of Cordova (pre-4.0), I think that instead of a crash, the user
> experience was the app just appeared to restart itself.
>
> At the very least, is there any possibility of better handling this
> scenario at a general level so it doesn't lead to a crash? I guess a
> targeted fix for the Camera plugin, to perhaps detect this and throw an
> error dialog, might be a start. I've also seen this with the barcode
> scanner plugin (which uses the camera). I don't know the policy on
> introducing localized strings in the core platform components, but if
> there's a way to handle that, it seems like showing the user a (native)
> notification that it failed would be appropriate.
>
> It may also be prudent to update the plugin development guide to discuss
> this issue and how to prevent crashes from referencing uninitialized
> instance variables in the intent callback.
>
> I may also play with Serge's solution and see if it is viable, and will
> report back what I find.
>
> Dan
>
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: Wednesday, June 03, 2015 11:44 AM
> To: dev@cordova.apache.org
> Subject: Re: Android plugin crash on resume when activity destroyed
>
> This has been a problem since we started, and there's no solution to it
> because there's no reliable way to restore state on a WebView. We have
> tried in the past, and failed miserably. I'm extremely skeptical that this
> would even work, since this apparently failed Travis. That said, if it
> does, every intent would have to manage their own state, and even when the
> plugin is loaded, we still don't know where in the app the user would be
> at, so returning a photo to a part of the DOM that doesn't even exist would
> have JS errors.
>
> Of course, this only happens when you're using a LOT of memory, like what
> Cameras tend to do, and other Intents, like for example, requesting
> permission to use a Tango Service on a Project Tango plugin, (
> https://github.com/infil00p/PhoneGapTango) or other third party plugins
> wouldn't run into the same problems.
>
> This is a problem with the Android architecture, and many native apps have
> run into similar problems. I don't think there's a solution for this in
> Cordova, and we have definitely tried.
>
> On Wed, Jun 3, 2015 at 9:46 AM Mefire O. <om...@microsoft.com> wrote:
>
> > Interesting fix, Serge. A question comes to mind:
> > - Since it seems like this issue affects all android plugins that call
> > other intents, won't we have to do this for all of them? Is there a way
> we
> > can leverage your PR and maybe come up with a general solution ? Maybe
> fit
> > the boilerplate code (state saving/restoring) somewhere all android
> plugins
> > can inherit ?
> >
> > On Jun 3, 2015 3:54 AM, Serge Huijben <s....@gmail.com> wrote:
> > what I did to solve this is add a check for callbackcontext, If that is
> > null save the incoming parameters.
> > if (this.callbackContext == null) {
> > this.savedRequestCode = requestCode;
> > this.savedResultCode = resultCode;
> > this.savedIntent = intent;
> > } else {
> > // procede as planned
> >
> > This is what happens after the activity has been killed by the system
> while
> > you are in the camera Intent.
> > Once you take or select your picture the mainactivity is restarted and
> with
> > it all the plugins, after which onActivityResult is fired.
> >
> > the code above saves the incoming parameters so they can be used later.
> > To do this I also added a new method, checkForSavedResults, specially for
> > Android, you call this method in your onDeviceReady javascript method
> that
> > will fire once the activity is restarted, and this will give you the
> > previously taken or selected picture.
> >
> > I put this in a pullrequest
> > https://github.com/apache/cordova-plugin-camera/pull/97
> > It solves Issue CB-8804 https://issues.apache.org/jira/browse/CB-8804
> >
> > hope this helps,
> >
> > Serge
> >
> >
> > Op di 2 jun. 2015 om 21:06 schreef Dan Polivy <da...@cellartracker.com>:
> >
> > > On Android, when using plugins that launch other intents, e.g. the
> Camera
> > > plugin, I'm now seeing reliable crashes when the cordova activity is
> > > resumed - if it was "destroyed" when the intent launched. The reliable
> > way
> > > to reproduce this is to enable the "Don't keep activities" setting in
> > > Android's Developer options. Based on the Google Play crash reports,
> this
> > > just started when we updated our app to use the new
> cordova-android@4.0.0
> > > <ma...@4.0.0> runtime.
> > >
> > > In the Camera plugin, the issue is that the
> > > CameraLauncher.processResultFromCamera method uses an instance
> variable,
> > > imageUri, which is set prior to launching the intent, but null when the
> > > activity is resumed. Presumably, this is because the plugin isn't aware
> > > that it needs to save state? Here's the full stack trace:
> > >
> > > java.lang.RuntimeException: Unable to resume activity {<app>}:
> > > java.lang.RuntimeException: Failure delivering result
> > ResultInfo{who=null,
> > > request=34, result=-1, data=null} to activity {<app>}:
> > > java.lang.NullPointerException: Attempt to invoke virtual method
> > > 'java.lang.String android.net.Uri.toString()' on a null object
> reference
> > > at
> > >
> >
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3349)
> > > at
> > >
> android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3380)
> > > at
> > >
> android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2731)
> > > at android.app.ActivityThread.access$900(ActivityThread.java:172)
> > > at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1421)
> > > at android.os.Handler.dispatchMessage(Handler.java:102)
> > > at android.os.Looper.loop(Looper.java:145)
> > > at android.app.ActivityThread.main(ActivityThread.java:5835)
> > > at java.lang.reflect.Method.invoke(Native Method)
> > > at java.lang.reflect.Method.invoke(Method.java:372)
> > > at
> > >
> >
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1388)
> > > at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1183)
> > > Caused by: java.lang.RuntimeException: Failure delivering result
> > > ResultInfo{who=null, request=34, result=-1, data=null} to activity
> > {<app>}:
> > > java.lang.NullPointerException: Attempt to invoke virtual method
> > > 'java.lang.String android.net.Uri.toString()' on a null object
> reference
> > > at android.app.ActivityThread.deliverResults(ActivityThread.java:3977)
> > > at
> > >
> >
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3335)
> > > ... 11 more
> > > Caused by: java.lang.NullPointerException: Attempt to invoke virtual
> > > method 'java.lang.String android.net.Uri.toString()' on a null object
> > > reference
> > > at
> > >
> >
> org.apache.cordova.camera.CameraLauncher.processResultFromCamera(CameraLauncher.java:445)
> > > at
> > >
> >
> org.apache.cordova.camera.CameraLauncher.onActivityResult(CameraLauncher.java:674)
> > > at
> > >
> >
> org.apache.cordova.CordovaInterfaceImpl.onActivityResult(CordovaInterfaceImpl.java:120)
> > > at
> > >
> >
> org.apache.cordova.CordovaActivity.onActivityResult(CordovaActivity.java:321)
> > > at android.app.Activity.dispatchActivityResult(Activity.java:6475)
> > > at android.app.ActivityThread.deliverResults(ActivityThread.java:3973)
> > > ... 12 more
> > >
> > > I've been looking at this for a bit, and am wondering whether this can
> > > even be supported with the current plugin architecture. I see that
> > onStart
> > > and onStop are now part of the plugin interface, but not
> > > onSaveInstanceState/onRestoreInstanceState. It seems like a fairly
> common
> > > pattern for plugins to save the CallbackContext, so this will impact
> more
> > > than just the Camera plugin.
> > >
> > > Has any thought gone into supporting this scenario? Is it possible to
> do
> > > with the current plugin interface, or would it need to be extended to
> add
> > > the instance state handlers to allow plugins to preserve necessary
> state?
> > > I'm happy to take a stab at addressing this, but would appreciate
> insight
> > > from the android native devs on the right way to approach this issue.
> (I
> > > haven't yet filed a JIRA issue on this, but will shortly.)
> > >
> > > Thanks,
> > > Dan
> > >
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
RE: Android plugin crash on resume when activity destroyed
Posted by Dan Polivy <da...@cellartracker.com>.
Interesting, thanks for the history, Joe and Serge.
I do probably agree with you, Joe, that this won't work well as it'll be hard to restore the DOM to the correct state. I can say that for my app, it's pretty unlikely to get exactly back to where you started. In prior versions of Cordova (pre-4.0), I think that instead of a crash, the user experience was the app just appeared to restart itself.
At the very least, is there any possibility of better handling this scenario at a general level so it doesn't lead to a crash? I guess a targeted fix for the Camera plugin, to perhaps detect this and throw an error dialog, might be a start. I've also seen this with the barcode scanner plugin (which uses the camera). I don't know the policy on introducing localized strings in the core platform components, but if there's a way to handle that, it seems like showing the user a (native) notification that it failed would be appropriate.
It may also be prudent to update the plugin development guide to discuss this issue and how to prevent crashes from referencing uninitialized instance variables in the intent callback.
I may also play with Serge's solution and see if it is viable, and will report back what I find.
Dan
-----Original Message-----
From: Joe Bowser [mailto:bowserj@gmail.com]
Sent: Wednesday, June 03, 2015 11:44 AM
To: dev@cordova.apache.org
Subject: Re: Android plugin crash on resume when activity destroyed
This has been a problem since we started, and there's no solution to it
because there's no reliable way to restore state on a WebView. We have
tried in the past, and failed miserably. I'm extremely skeptical that this
would even work, since this apparently failed Travis. That said, if it
does, every intent would have to manage their own state, and even when the
plugin is loaded, we still don't know where in the app the user would be
at, so returning a photo to a part of the DOM that doesn't even exist would
have JS errors.
Of course, this only happens when you're using a LOT of memory, like what
Cameras tend to do, and other Intents, like for example, requesting
permission to use a Tango Service on a Project Tango plugin, (
https://github.com/infil00p/PhoneGapTango) or other third party plugins
wouldn't run into the same problems.
This is a problem with the Android architecture, and many native apps have
run into similar problems. I don't think there's a solution for this in
Cordova, and we have definitely tried.
On Wed, Jun 3, 2015 at 9:46 AM Mefire O. <om...@microsoft.com> wrote:
> Interesting fix, Serge. A question comes to mind:
> - Since it seems like this issue affects all android plugins that call
> other intents, won't we have to do this for all of them? Is there a way we
> can leverage your PR and maybe come up with a general solution ? Maybe fit
> the boilerplate code (state saving/restoring) somewhere all android plugins
> can inherit ?
>
> On Jun 3, 2015 3:54 AM, Serge Huijben <s....@gmail.com> wrote:
> what I did to solve this is add a check for callbackcontext, If that is
> null save the incoming parameters.
> if (this.callbackContext == null) {
> this.savedRequestCode = requestCode;
> this.savedResultCode = resultCode;
> this.savedIntent = intent;
> } else {
> // procede as planned
>
> This is what happens after the activity has been killed by the system while
> you are in the camera Intent.
> Once you take or select your picture the mainactivity is restarted and with
> it all the plugins, after which onActivityResult is fired.
>
> the code above saves the incoming parameters so they can be used later.
> To do this I also added a new method, checkForSavedResults, specially for
> Android, you call this method in your onDeviceReady javascript method that
> will fire once the activity is restarted, and this will give you the
> previously taken or selected picture.
>
> I put this in a pullrequest
> https://github.com/apache/cordova-plugin-camera/pull/97
> It solves Issue CB-8804 https://issues.apache.org/jira/browse/CB-8804
>
> hope this helps,
>
> Serge
>
>
> Op di 2 jun. 2015 om 21:06 schreef Dan Polivy <da...@cellartracker.com>:
>
> > On Android, when using plugins that launch other intents, e.g. the Camera
> > plugin, I'm now seeing reliable crashes when the cordova activity is
> > resumed - if it was "destroyed" when the intent launched. The reliable
> way
> > to reproduce this is to enable the "Don't keep activities" setting in
> > Android's Developer options. Based on the Google Play crash reports, this
> > just started when we updated our app to use the new cordova-android@4.0.0
> > <ma...@4.0.0> runtime.
> >
> > In the Camera plugin, the issue is that the
> > CameraLauncher.processResultFromCamera method uses an instance variable,
> > imageUri, which is set prior to launching the intent, but null when the
> > activity is resumed. Presumably, this is because the plugin isn't aware
> > that it needs to save state? Here's the full stack trace:
> >
> > java.lang.RuntimeException: Unable to resume activity {<app>}:
> > java.lang.RuntimeException: Failure delivering result
> ResultInfo{who=null,
> > request=34, result=-1, data=null} to activity {<app>}:
> > java.lang.NullPointerException: Attempt to invoke virtual method
> > 'java.lang.String android.net.Uri.toString()' on a null object reference
> > at
> >
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3349)
> > at
> > android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3380)
> > at
> > android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2731)
> > at android.app.ActivityThread.access$900(ActivityThread.java:172)
> > at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1421)
> > at android.os.Handler.dispatchMessage(Handler.java:102)
> > at android.os.Looper.loop(Looper.java:145)
> > at android.app.ActivityThread.main(ActivityThread.java:5835)
> > at java.lang.reflect.Method.invoke(Native Method)
> > at java.lang.reflect.Method.invoke(Method.java:372)
> > at
> >
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1388)
> > at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1183)
> > Caused by: java.lang.RuntimeException: Failure delivering result
> > ResultInfo{who=null, request=34, result=-1, data=null} to activity
> {<app>}:
> > java.lang.NullPointerException: Attempt to invoke virtual method
> > 'java.lang.String android.net.Uri.toString()' on a null object reference
> > at android.app.ActivityThread.deliverResults(ActivityThread.java:3977)
> > at
> >
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3335)
> > ... 11 more
> > Caused by: java.lang.NullPointerException: Attempt to invoke virtual
> > method 'java.lang.String android.net.Uri.toString()' on a null object
> > reference
> > at
> >
> org.apache.cordova.camera.CameraLauncher.processResultFromCamera(CameraLauncher.java:445)
> > at
> >
> org.apache.cordova.camera.CameraLauncher.onActivityResult(CameraLauncher.java:674)
> > at
> >
> org.apache.cordova.CordovaInterfaceImpl.onActivityResult(CordovaInterfaceImpl.java:120)
> > at
> >
> org.apache.cordova.CordovaActivity.onActivityResult(CordovaActivity.java:321)
> > at android.app.Activity.dispatchActivityResult(Activity.java:6475)
> > at android.app.ActivityThread.deliverResults(ActivityThread.java:3973)
> > ... 12 more
> >
> > I've been looking at this for a bit, and am wondering whether this can
> > even be supported with the current plugin architecture. I see that
> onStart
> > and onStop are now part of the plugin interface, but not
> > onSaveInstanceState/onRestoreInstanceState. It seems like a fairly common
> > pattern for plugins to save the CallbackContext, so this will impact more
> > than just the Camera plugin.
> >
> > Has any thought gone into supporting this scenario? Is it possible to do
> > with the current plugin interface, or would it need to be extended to add
> > the instance state handlers to allow plugins to preserve necessary state?
> > I'm happy to take a stab at addressing this, but would appreciate insight
> > from the android native devs on the right way to approach this issue. (I
> > haven't yet filed a JIRA issue on this, but will shortly.)
> >
> > Thanks,
> > Dan
> >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Android plugin crash on resume when activity destroyed
Posted by Joe Bowser <bo...@gmail.com>.
This has been a problem since we started, and there's no solution to it
because there's no reliable way to restore state on a WebView. We have
tried in the past, and failed miserably. I'm extremely skeptical that this
would even work, since this apparently failed Travis. That said, if it
does, every intent would have to manage their own state, and even when the
plugin is loaded, we still don't know where in the app the user would be
at, so returning a photo to a part of the DOM that doesn't even exist would
have JS errors.
Of course, this only happens when you're using a LOT of memory, like what
Cameras tend to do, and other Intents, like for example, requesting
permission to use a Tango Service on a Project Tango plugin, (
https://github.com/infil00p/PhoneGapTango) or other third party plugins
wouldn't run into the same problems.
This is a problem with the Android architecture, and many native apps have
run into similar problems. I don't think there's a solution for this in
Cordova, and we have definitely tried.
On Wed, Jun 3, 2015 at 9:46 AM Mefire O. <om...@microsoft.com> wrote:
> Interesting fix, Serge. A question comes to mind:
> - Since it seems like this issue affects all android plugins that call
> other intents, won't we have to do this for all of them? Is there a way we
> can leverage your PR and maybe come up with a general solution ? Maybe fit
> the boilerplate code (state saving/restoring) somewhere all android plugins
> can inherit ?
>
> On Jun 3, 2015 3:54 AM, Serge Huijben <s....@gmail.com> wrote:
> what I did to solve this is add a check for callbackcontext, If that is
> null save the incoming parameters.
> if (this.callbackContext == null) {
> this.savedRequestCode = requestCode;
> this.savedResultCode = resultCode;
> this.savedIntent = intent;
> } else {
> // procede as planned
>
> This is what happens after the activity has been killed by the system while
> you are in the camera Intent.
> Once you take or select your picture the mainactivity is restarted and with
> it all the plugins, after which onActivityResult is fired.
>
> the code above saves the incoming parameters so they can be used later.
> To do this I also added a new method, checkForSavedResults, specially for
> Android, you call this method in your onDeviceReady javascript method that
> will fire once the activity is restarted, and this will give you the
> previously taken or selected picture.
>
> I put this in a pullrequest
> https://github.com/apache/cordova-plugin-camera/pull/97
> It solves Issue CB-8804 https://issues.apache.org/jira/browse/CB-8804
>
> hope this helps,
>
> Serge
>
>
> Op di 2 jun. 2015 om 21:06 schreef Dan Polivy <da...@cellartracker.com>:
>
> > On Android, when using plugins that launch other intents, e.g. the Camera
> > plugin, I'm now seeing reliable crashes when the cordova activity is
> > resumed - if it was "destroyed" when the intent launched. The reliable
> way
> > to reproduce this is to enable the "Don't keep activities" setting in
> > Android's Developer options. Based on the Google Play crash reports, this
> > just started when we updated our app to use the new cordova-android@4.0.0
> > <ma...@4.0.0> runtime.
> >
> > In the Camera plugin, the issue is that the
> > CameraLauncher.processResultFromCamera method uses an instance variable,
> > imageUri, which is set prior to launching the intent, but null when the
> > activity is resumed. Presumably, this is because the plugin isn't aware
> > that it needs to save state? Here's the full stack trace:
> >
> > java.lang.RuntimeException: Unable to resume activity {<app>}:
> > java.lang.RuntimeException: Failure delivering result
> ResultInfo{who=null,
> > request=34, result=-1, data=null} to activity {<app>}:
> > java.lang.NullPointerException: Attempt to invoke virtual method
> > 'java.lang.String android.net.Uri.toString()' on a null object reference
> > at
> >
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3349)
> > at
> > android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3380)
> > at
> > android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2731)
> > at android.app.ActivityThread.access$900(ActivityThread.java:172)
> > at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1421)
> > at android.os.Handler.dispatchMessage(Handler.java:102)
> > at android.os.Looper.loop(Looper.java:145)
> > at android.app.ActivityThread.main(ActivityThread.java:5835)
> > at java.lang.reflect.Method.invoke(Native Method)
> > at java.lang.reflect.Method.invoke(Method.java:372)
> > at
> >
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1388)
> > at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1183)
> > Caused by: java.lang.RuntimeException: Failure delivering result
> > ResultInfo{who=null, request=34, result=-1, data=null} to activity
> {<app>}:
> > java.lang.NullPointerException: Attempt to invoke virtual method
> > 'java.lang.String android.net.Uri.toString()' on a null object reference
> > at android.app.ActivityThread.deliverResults(ActivityThread.java:3977)
> > at
> >
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3335)
> > ... 11 more
> > Caused by: java.lang.NullPointerException: Attempt to invoke virtual
> > method 'java.lang.String android.net.Uri.toString()' on a null object
> > reference
> > at
> >
> org.apache.cordova.camera.CameraLauncher.processResultFromCamera(CameraLauncher.java:445)
> > at
> >
> org.apache.cordova.camera.CameraLauncher.onActivityResult(CameraLauncher.java:674)
> > at
> >
> org.apache.cordova.CordovaInterfaceImpl.onActivityResult(CordovaInterfaceImpl.java:120)
> > at
> >
> org.apache.cordova.CordovaActivity.onActivityResult(CordovaActivity.java:321)
> > at android.app.Activity.dispatchActivityResult(Activity.java:6475)
> > at android.app.ActivityThread.deliverResults(ActivityThread.java:3973)
> > ... 12 more
> >
> > I've been looking at this for a bit, and am wondering whether this can
> > even be supported with the current plugin architecture. I see that
> onStart
> > and onStop are now part of the plugin interface, but not
> > onSaveInstanceState/onRestoreInstanceState. It seems like a fairly common
> > pattern for plugins to save the CallbackContext, so this will impact more
> > than just the Camera plugin.
> >
> > Has any thought gone into supporting this scenario? Is it possible to do
> > with the current plugin interface, or would it need to be extended to add
> > the instance state handlers to allow plugins to preserve necessary state?
> > I'm happy to take a stab at addressing this, but would appreciate insight
> > from the android native devs on the right way to approach this issue. (I
> > haven't yet filed a JIRA issue on this, but will shortly.)
> >
> > Thanks,
> > Dan
> >
> >
> >
>
Re: Android plugin crash on resume when activity destroyed
Posted by "Mefire O." <om...@microsoft.com>.
Interesting fix, Serge. A question comes to mind:
- Since it seems like this issue affects all android plugins that call other intents, won't we have to do this for all of them? Is there a way we can leverage your PR and maybe come up with a general solution ? Maybe fit the boilerplate code (state saving/restoring) somewhere all android plugins can inherit ?
On Jun 3, 2015 3:54 AM, Serge Huijben <s....@gmail.com> wrote:
what I did to solve this is add a check for callbackcontext, If that is
null save the incoming parameters.
if (this.callbackContext == null) {
this.savedRequestCode = requestCode;
this.savedResultCode = resultCode;
this.savedIntent = intent;
} else {
// procede as planned
This is what happens after the activity has been killed by the system while
you are in the camera Intent.
Once you take or select your picture the mainactivity is restarted and with
it all the plugins, after which onActivityResult is fired.
the code above saves the incoming parameters so they can be used later.
To do this I also added a new method, checkForSavedResults, specially for
Android, you call this method in your onDeviceReady javascript method that
will fire once the activity is restarted, and this will give you the
previously taken or selected picture.
I put this in a pullrequest
https://github.com/apache/cordova-plugin-camera/pull/97
It solves Issue CB-8804 https://issues.apache.org/jira/browse/CB-8804
hope this helps,
Serge
Op di 2 jun. 2015 om 21:06 schreef Dan Polivy <da...@cellartracker.com>:
> On Android, when using plugins that launch other intents, e.g. the Camera
> plugin, I'm now seeing reliable crashes when the cordova activity is
> resumed - if it was "destroyed" when the intent launched. The reliable way
> to reproduce this is to enable the "Don't keep activities" setting in
> Android's Developer options. Based on the Google Play crash reports, this
> just started when we updated our app to use the new cordova-android@4.0.0
> <ma...@4.0.0> runtime.
>
> In the Camera plugin, the issue is that the
> CameraLauncher.processResultFromCamera method uses an instance variable,
> imageUri, which is set prior to launching the intent, but null when the
> activity is resumed. Presumably, this is because the plugin isn't aware
> that it needs to save state? Here's the full stack trace:
>
> java.lang.RuntimeException: Unable to resume activity {<app>}:
> java.lang.RuntimeException: Failure delivering result ResultInfo{who=null,
> request=34, result=-1, data=null} to activity {<app>}:
> java.lang.NullPointerException: Attempt to invoke virtual method
> 'java.lang.String android.net.Uri.toString()' on a null object reference
> at
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3349)
> at
> android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3380)
> at
> android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2731)
> at android.app.ActivityThread.access$900(ActivityThread.java:172)
> at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1421)
> at android.os.Handler.dispatchMessage(Handler.java:102)
> at android.os.Looper.loop(Looper.java:145)
> at android.app.ActivityThread.main(ActivityThread.java:5835)
> at java.lang.reflect.Method.invoke(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:372)
> at
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1388)
> at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1183)
> Caused by: java.lang.RuntimeException: Failure delivering result
> ResultInfo{who=null, request=34, result=-1, data=null} to activity {<app>}:
> java.lang.NullPointerException: Attempt to invoke virtual method
> 'java.lang.String android.net.Uri.toString()' on a null object reference
> at android.app.ActivityThread.deliverResults(ActivityThread.java:3977)
> at
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3335)
> ... 11 more
> Caused by: java.lang.NullPointerException: Attempt to invoke virtual
> method 'java.lang.String android.net.Uri.toString()' on a null object
> reference
> at
> org.apache.cordova.camera.CameraLauncher.processResultFromCamera(CameraLauncher.java:445)
> at
> org.apache.cordova.camera.CameraLauncher.onActivityResult(CameraLauncher.java:674)
> at
> org.apache.cordova.CordovaInterfaceImpl.onActivityResult(CordovaInterfaceImpl.java:120)
> at
> org.apache.cordova.CordovaActivity.onActivityResult(CordovaActivity.java:321)
> at android.app.Activity.dispatchActivityResult(Activity.java:6475)
> at android.app.ActivityThread.deliverResults(ActivityThread.java:3973)
> ... 12 more
>
> I've been looking at this for a bit, and am wondering whether this can
> even be supported with the current plugin architecture. I see that onStart
> and onStop are now part of the plugin interface, but not
> onSaveInstanceState/onRestoreInstanceState. It seems like a fairly common
> pattern for plugins to save the CallbackContext, so this will impact more
> than just the Camera plugin.
>
> Has any thought gone into supporting this scenario? Is it possible to do
> with the current plugin interface, or would it need to be extended to add
> the instance state handlers to allow plugins to preserve necessary state?
> I'm happy to take a stab at addressing this, but would appreciate insight
> from the android native devs on the right way to approach this issue. (I
> haven't yet filed a JIRA issue on this, but will shortly.)
>
> Thanks,
> Dan
>
>
>
Re: Android plugin crash on resume when activity destroyed
Posted by Serge Huijben <s....@gmail.com>.
what I did to solve this is add a check for callbackcontext, If that is
null save the incoming parameters.
if (this.callbackContext == null) {
this.savedRequestCode = requestCode;
this.savedResultCode = resultCode;
this.savedIntent = intent;
} else {
// procede as planned
This is what happens after the activity has been killed by the system while
you are in the camera Intent.
Once you take or select your picture the mainactivity is restarted and with
it all the plugins, after which onActivityResult is fired.
the code above saves the incoming parameters so they can be used later.
To do this I also added a new method, checkForSavedResults, specially for
Android, you call this method in your onDeviceReady javascript method that
will fire once the activity is restarted, and this will give you the
previously taken or selected picture.
I put this in a pullrequest
https://github.com/apache/cordova-plugin-camera/pull/97
It solves Issue CB-8804 https://issues.apache.org/jira/browse/CB-8804
hope this helps,
Serge
Op di 2 jun. 2015 om 21:06 schreef Dan Polivy <da...@cellartracker.com>:
> On Android, when using plugins that launch other intents, e.g. the Camera
> plugin, I'm now seeing reliable crashes when the cordova activity is
> resumed - if it was "destroyed" when the intent launched. The reliable way
> to reproduce this is to enable the "Don't keep activities" setting in
> Android's Developer options. Based on the Google Play crash reports, this
> just started when we updated our app to use the new cordova-android@4.0.0
> <ma...@4.0.0> runtime.
>
> In the Camera plugin, the issue is that the
> CameraLauncher.processResultFromCamera method uses an instance variable,
> imageUri, which is set prior to launching the intent, but null when the
> activity is resumed. Presumably, this is because the plugin isn't aware
> that it needs to save state? Here's the full stack trace:
>
> java.lang.RuntimeException: Unable to resume activity {<app>}:
> java.lang.RuntimeException: Failure delivering result ResultInfo{who=null,
> request=34, result=-1, data=null} to activity {<app>}:
> java.lang.NullPointerException: Attempt to invoke virtual method
> 'java.lang.String android.net.Uri.toString()' on a null object reference
> at
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3349)
> at
> android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3380)
> at
> android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2731)
> at android.app.ActivityThread.access$900(ActivityThread.java:172)
> at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1421)
> at android.os.Handler.dispatchMessage(Handler.java:102)
> at android.os.Looper.loop(Looper.java:145)
> at android.app.ActivityThread.main(ActivityThread.java:5835)
> at java.lang.reflect.Method.invoke(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:372)
> at
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1388)
> at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1183)
> Caused by: java.lang.RuntimeException: Failure delivering result
> ResultInfo{who=null, request=34, result=-1, data=null} to activity {<app>}:
> java.lang.NullPointerException: Attempt to invoke virtual method
> 'java.lang.String android.net.Uri.toString()' on a null object reference
> at android.app.ActivityThread.deliverResults(ActivityThread.java:3977)
> at
> android.app.ActivityThread.performResumeActivity(ActivityThread.java:3335)
> ... 11 more
> Caused by: java.lang.NullPointerException: Attempt to invoke virtual
> method 'java.lang.String android.net.Uri.toString()' on a null object
> reference
> at
> org.apache.cordova.camera.CameraLauncher.processResultFromCamera(CameraLauncher.java:445)
> at
> org.apache.cordova.camera.CameraLauncher.onActivityResult(CameraLauncher.java:674)
> at
> org.apache.cordova.CordovaInterfaceImpl.onActivityResult(CordovaInterfaceImpl.java:120)
> at
> org.apache.cordova.CordovaActivity.onActivityResult(CordovaActivity.java:321)
> at android.app.Activity.dispatchActivityResult(Activity.java:6475)
> at android.app.ActivityThread.deliverResults(ActivityThread.java:3973)
> ... 12 more
>
> I've been looking at this for a bit, and am wondering whether this can
> even be supported with the current plugin architecture. I see that onStart
> and onStop are now part of the plugin interface, but not
> onSaveInstanceState/onRestoreInstanceState. It seems like a fairly common
> pattern for plugins to save the CallbackContext, so this will impact more
> than just the Camera plugin.
>
> Has any thought gone into supporting this scenario? Is it possible to do
> with the current plugin interface, or would it need to be extended to add
> the instance state handlers to allow plugins to preserve necessary state?
> I'm happy to take a stab at addressing this, but would appreciate insight
> from the android native devs on the right way to approach this issue. (I
> haven't yet filed a JIRA issue on this, but will shortly.)
>
> Thanks,
> Dan
>
>
>