UPDATE: This issue does turn out to be due to not having defined --mobile-settings on meteor build. That option seems not to be documented anywhere (why not?) except in the meteor build help command line usage text. It explains the Meteor.settings.public being undefined, since --mobile-settings is exactly what defines those settings, as @rjdavid suggested. I had conflated --settings and --mobile-server in my addled mind with the idea of --mobile-settings, and didn’t recognize it as another different command line option. Argh.
As for the two deviceready events, that seems likely to be due to hot code push reloading the app, and generating deviceready from cordova two times. Strangely, I now have another different issue with a vendor cordova plugin, as it blows up on the 2nd deviceready because the plugin is not competely reset by HCP, even though the app is reset enough to generate two deviceready events.
This has been quite painful to unravel, so I’ll leave it here in case it’s helpful to anyone.
END OF UPDATE
I’ve spent a bunch of time trying to figure out what’s going on here, and I’ve just discovered something that I need explained to me.
My cordova app is failing with a white screen the first time it runs after install, but it works every time after that. The error is that ‘public’ is being accessed in an undefined Meteor.settings, but that’s not because of any of the other reasons that Meteor.settings can be undefined. The app works fine in iOS and browser, but as with Android, does send two deviceready events.
Here’s the part that seems really weird. On the first (and ONLY the first) run of the Android app after install, this is the error that kills it:
01-28 18:56:47.865 12761 12761 D SystemWebChromeClient: http://localhost:12072/__cordova/ 0c7c3edd55efd812f6df0f23380f7f765d0ae2a9.js?meteor_js_resource=true: Line 157 : Received Event: deviceready . . . 01-28 18:56:48.425 12761 12761 I chromium: [INFO:CONSOLE(1)] "TypeError: Cannot read property 'public' of undefined 01-28 18:56:48.425 12761 12761 I chromium: at t.e [as render] (http://localhost:12072/__cordova/ 0c7c3edd55efd812f6df0f23380f7f765d0ae2a9.js?meteor_js_resource=true:157:187695)
157:187695 refers to an innocuous Meteor.settings.public definition that is properly defined and works on all other platforms (and on Android after the initial crash). On all subsequent runs, though, the code works properly and doesn’t crash.
Can anyone shed light on this, please? Thanks!