Lengthy description ahead - you have been warned. :-) I've run into a situation with a Cordova application that uses the cordova-plugin-crosswalk-webview (v2.1.0, Crosswalk v21 stable). The application is used in a kiosk-mode application on an Android tablet. As such, the application is launched when the tablet is powered up and locked into kiosk mode so that other applications cannot be switched to.
I have observed that sometimes (frequently, but not every time) the application crashes on tablet power up with the following exception: 10-19 11:52:02.368 3108 - E AndroidRuntime java.lang.RuntimeException: The context of initialization is not consistent 10-19 11:52:02.368 3108 - E AndroidRuntime at org.xwalk.core.XWalkEnvironment.finishInit(XWalkEnvironment.java:50) 10-19 11:52:02.368 3108 - E AndroidRuntime at org.xwalk.core.XWalkLibraryLoader$ActivateTask.onPostExecute(XWalkLibraryLoader.java:347) 10-19 11:52:02.368 3108 - E AndroidRuntime at org.xwalk.core.XWalkLibraryLoader$ActivateTask.onPostExecute(XWalkLibraryLoader.java:317) 10-19 11:52:02.368 3108 - E AndroidRuntime at android.os.AsyncTask.finish(AsyncTask.java:651) 10-19 11:52:02.368 3108 - E AndroidRuntime at android.os.AsyncTask.access$500(AsyncTask.java:180) 10-19 11:52:02.368 3108 - E AndroidRuntime at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:668) 10-19 11:52:02.368 3108 - E AndroidRuntime at android.os.Handler.dispatchMessage(Handler.java:102) 10-19 11:52:02.368 3108 - E AndroidRuntime at android.os.Looper.loop(Looper.java:148) 10-19 11:52:02.368 3108 - E AndroidRuntime at android.app.ActivityThread.main(ActivityThread.java:7325) 10-19 11:52:02.368 3108 - E AndroidRuntime at java.lang.reflect.Method.invoke(Native Method) 10-19 11:52:02.368 3108 - E AndroidRuntime at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1230) 10-19 11:52:02.368 3108 - E AndroidRuntime at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1120) By adding some logging to the Cordova activity, I was able to observe that the application reaches onCreate, then onDestroy, then onCreate again (with a non-null Bundle parameter the second time), implying to me that the activity has been stopped by Android and restarted. Many of the typical configuration changes that can restart an activity have already been accounted for in AndroidManifest.xml: <activity android:configChanges="orientation|keyboardHidden|keyboard|screenSize|locale" ... />. I also did some testing to prevent activity restart for the other documented Android configChanges, to no effect - the re-start still occurred. Since a configChange doesn't seem to be the culprit, I believe that sometimes during boot time, as the many processes are spinning up, Android decides to stop the Cordova activity and restart it, perhaps due to resource limitations. This restart happens before the Crosswalk library loading thread is finished, resulting in a different context for the finishInit() function in XWalkEnvironment. I used a local canary build (23.52.585.0) with the plugin and generated a similar crash at startup with a different stack trace: 10-19 18:04:26.613 3112 - E AndroidRuntime java.lang.RuntimeException: Crosswalk's APIs are not ready yet 10-19 18:04:26.613 3112 - E AndroidRuntime at org.xwalk.core.XWalkView.setZOrderOnTop(XWalkView.java:1514) 10-19 18:04:26.613 3112 - E AndroidRuntime at org.crosswalk.engine.XWalkWebViewEngine.initWebViewSettings(XWalkWebViewEngine.java:194) 10-19 18:04:26.613 3112 - E AndroidRuntime at org.crosswalk.engine.XWalkWebViewEngine.access$000(XWalkWebViewEngine.java:56) 10-19 18:04:26.613 3112 - E AndroidRuntime at org.crosswalk.engine.XWalkWebViewEngine$2.run(XWalkWebViewEngine.java:91) 10-19 18:04:26.613 3112 - E AndroidRuntime at org.xwalk.core.XWalkActivityDelegate.onActivateCompleted(XWalkActivityDelegate.java:172) 10-19 18:04:26.613 3112 - E AndroidRuntime at org.xwalk.core.XWalkLibraryLoader$ActivateTask.onPostExecute(XWalkLibraryLoader.java:349) 10-19 18:04:26.613 3112 - E AndroidRuntime at org.xwalk.core.XWalkLibraryLoader$ActivateTask.onPostExecute(XWalkLibraryLoader.java:317) 10-19 18:04:26.613 3112 - E AndroidRuntime at android.os.AsyncTask.finish(AsyncTask.java:651) 10-19 18:04:26.613 3112 - E AndroidRuntime at android.os.AsyncTask.access$500(AsyncTask.java:180) 10-19 18:04:26.613 3112 - E AndroidRuntime at android.os.AsyncTask$InternalHandler.handleMessage(AsyncTask.java:668) 10-19 18:04:26.613 3112 - E AndroidRuntime at android.os.Handler.dispatchMessage(Handler.java:102) 10-19 18:04:26.613 3112 - E AndroidRuntime at android.os.Looper.loop(Looper.java:148) 10-19 18:04:26.613 3112 - E AndroidRuntime at android.app.ActivityThread.main(ActivityThread.java:7325) 10-19 18:04:26.613 3112 - E AndroidRuntime at java.lang.reflect.Method.invoke(Native Method) 10-19 18:04:26.613 3112 - E AndroidRuntime at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1230) 10-19 18:04:26.613 3112 - E AndroidRuntime at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1120) I believe this different stack trace is due to a refactoring in Crosswalk to remove a coupling of the webview with the Android activity, but I think the origin of the problem I'm seeing in both versions of Crosswalk is similarly-rooted. My question is: can I restructure anything in Android side of my Cordova app to give Crosswalk the hint the activity has re-started -- giving it a chance to update the context or otherwise reload the library? It is currently a vanilla Cordova app, with no customization of the generated Java code. Thanks if you've read this far! :-) Regards, Tom Drewes
_______________________________________________ Crosswalk-help mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-help
