This issue needs help from Motorola. We will raise this issue with them to get an answer.
Further information regarding the issue reported:
The error occurs if the other applications are running in the foreground for a period of time.
The above error is not always logged when the application is terminated in this manner but it would seem that the issue is that the RhoMobile application is being closed by the Android device due to inactivity or to recover resources. I had recently posted a question regarding this issue as it came to light that this may be occurring.
We have now seen the safeGetInstance error when the application was running in the foreground.
The device reported the message that the application had closed and then restarted the application.
To try and investigate this problem, we started up the Rho application and then switched to several other applications in turn to force the Rho application to be destroyed underneath.
We put some debugging logging onto the various Rho::RhoApplication events to monitor the activation/deactivation, creation/destruction events.
In the logs on the device we can see that the following was happening:
15:15:42.356 on_ui_destroyed called
15:15:43.849 on_deactivate_app called
15:16:23.045 RhodesAppJNI| nativeNotify
15:16:23.055 RhodesApp| enter notifyReceiver
15:16:23.056 RhodesApp| calling onNetworkStatusChanged
15:16:23.421 initialize called
15:16:23.480 bind keycapture called
15:16:23.486 WebView| RhodesActivity.sInstance == null java.lang.NullPointerException
15:16:23.494 initialize complete
15:22:53.020 on_ui_created called
15:22:53.071 on_activate_app called
This tells us that the issue was that the following step (we are using it to block the back button) was causing the error in the initialize method:
Rho::KeyCapture.captureKey(false, "4", '/app/Settings/keyCallback');
What concerns me more is that the initialize method seems to have been called at the point where the application was destroyed (15:16) rather than when we reactivated the application (15:22). This may or may not be intended behaviour, but the lack of UI at 15:16 is why the captureKey had nothing to bind to.
If the initialize method is called as soon as the application is destroyed (presumably to immediately restart some of its elements) then is there any way to use this to restore the session to its previous state?