android: com.tns.NativeScriptException - MetaData cannot be opened.
Been seeing this crash report at an alarming rate lately
java.lang.RuntimeException:
at android.app.ActivityThread.handleBindApplication (ActivityThread.java:6214)
at android.app.ActivityThread.access$1200 (ActivityThread.java:236)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1784)
at android.os.Handler.dispatchMessage (Handler.java:106)
at android.os.Looper.loop (Looper.java:214)
at android.app.ActivityThread.main (ActivityThread.java:7037)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:494)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:965)
Caused by: com.tns.NativeScriptException:
at com.tns.Runtime.initNativeScript (Native Method)
at com.tns.Runtime.init (Runtime.java:627)
at com.tns.Runtime.init (Runtime.java:601)
at com.tns.Runtime.initRuntime (Runtime.java:591)
at com.tns.Runtime.initializeRuntimeWithConfiguration (Runtime.java:566)
at com.tns.RuntimeHelper.initRuntime (RuntimeHelper.java:163)
at com.tns.NativeScriptApplication.onCreate (NativeScriptApplication.java:20)
at android.app.Instrumentation.callApplicationOnCreate (Instrumentation.java:1154)
at android.app.ActivityThread.handleBindApplication (ActivityThread.java:6209)
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 4
- Comments: 80 (43 by maintainers)
Ok, after much testing and trying many different things this week and a LOT of googling; I finally figured out solidly what exactly is happening and a PR has been created! Yay!
In a nutshell; the answer is for the app to exit with no error code in this specific corner case event (basically what it used to do before NS 6.2 added NEEDED error tracking to this section of the code).
For those interested in the details:
DIRECT_BOOT. (https://developer.android.com/training/articles/direct-boot) this allows a app to startup while the phone has started up and has never been unlocked and only a few types of apps are supposed to use it…Sounds cool huh? 😀 In
DIRECT_BOOTthe normal storage is supposed to remain locked and unavailable; so then the application cannot get access to any files. They even have a special api that aDIRECT_BOOTreceiver can use for secure storage. Apparently, in Android 9 most vendors finally enforced that the application actually cannot get access to any files and can ONLY use the access to the special API for storage.So the end results after much testing is:
Device Unlocked at startup: Receiver -> NativeScript -> Load MetaData -> Exit Normally
Device Locked at startup: Receiver -> NativeScript -> Load MetaData -> Error 2 -> Exit normally in this special corner case.
Both cases basically act the same now, and the user should not see any negative behavior nor should you see the google ding your app for crashes…
@NathanaelA We released our app with the android runtime v6.5.3 a few days ago. No more alarming crash rates.
Thanks again for all your time on this.
Just updated to 6.5.2, sadly
tns run androidfails with:…/testcrash/platforms/android/build-tools/buildMetadata.log:
Steps to reproduce:
Is there anything else that needs to be updated?
@jessorlisa - Yes, actually I plan on trying to release a 6.5.2 version this weekend that contains just this patch, then at the same time a new 6.6.0 version that contains the new v8 engine upgrade and it will also include this patch.
WooHoo - Lock screen seems to matter for my testing. Activated it and locked the device; rebooted. And the error showed up. Same thing, logged in, locked the screen, restarted error showed up again. YAY!!!
@7ammer - James, the Pixel phone is supposed to arrive tomorrow afternoon at the local fedex facility; I should be able to pick it up Thursday; and actually see if I can duplicate it Thursday night. 😃
NativeScriptException is a generell exception for everything but different issues, we should split up the Thread into different issues, otherwise we loose overview and never solve anything.
The Stack + Exception Message really matters currently, since nativescript doesnt implement sub exceptions what i already said here.
That is the reason why I haven’t PRed those changes to the runtime. I’m aware that it is just masking it. It was put in there just as a workaround while I wait for the actual fix.
i think thats something else or at least not matching the stack everyone else has here and doesnt belong here and should be an own issue?
Notifications themself are not an issue. It is enough to add the plugin via
tns plugin add nativescript-local-notifications- without any implementation.Hello,
After further investigation we were able to reproduce it.
Last stable version is 6.1.2. On all versions above you can reproduce it following:
we were able to fetch a full stacktrace like this with following error message:
Why is google not reporting the full message? If this is known, nativescript should maybe implement subclasses of the NativeScriptException, to identify further whats the cause of issues like this…
Also we had following crash on nativescript 6.1.2 (maybe off topic, maybe related, but it happened only once and its not reproducable):
java.lang.RuntimeException: at android.app.ActivityThread.handleBindApplication (ActivityThread.java:6465) at android.app.ActivityThread.access$1300 (ActivityThread.java:219) at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1859) at android.os.Handler.dispatchMessage (Handler.java:107) at android.os.Looper.loop (Looper.java:214) at android.app.ActivityThread.main (ActivityThread.java:7356) at java.lang.reflect.Method.invoke (Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:492) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:930) Caused by: com.tns.NativeScriptException: at com.tns.Runtime.initNativeScript (Native Method) at com.tns.Runtime.init (Runtime.java:627) at com.tns.Runtime.init (Runtime.java:601) at com.tns.Runtime.initRuntime (Runtime.java:591) at com.tns.Runtime.initializeRuntimeWithConfiguration (Runtime.java:566) at com.tns.RuntimeHelper.initRuntime (RuntimeHelper.java:163) at com.tns.NativeScriptApplication.onCreate (NativeScriptApplication.java:19) at android.app.Instrumentation.callApplicationOnCreate (Instrumentation.java:1189) at android.app.ActivityThread.handleBindApplication (ActivityThread.java:6460)This is from the Play Console. And yes, my latest production release is the first to include Local-Notifications. I haven’t seen these errors before.
And this is the list of devices:
Just so you are aware, I have cleaned up the issue and hide comments (including some of mine 😀) that are out of scope; and moved @ptrxwsmitt Patricks issue into a new issue. :
As for status of this;
I do know why the error is being thrown in 6.2+; it is because this error message actually didn’t exist in the prior version of NS and so the app silently exited. So this same issue was occurring in prior version, it just was a silent exit.
I’m waiting for the phone to get here; none of my test phones exhibit this issue, so I have a Pixel on the way — unfortunately where I live shipping is SLOW. As soon as I get a device we can see if we can determine the actual why. I have a few ideas why this is failing but without being able to duplicate it – I can’t really test or fix it…
@Peterf89 & @neil-119 Do you have a callstack, and/or can you confirm you are using the Local-notifications plugin?
I’m seeing the same issue with the metadata folder not being able to be opened on Pixel 3 XL. Downgrading tns-android did not work. Any workarounds? It’s a new project.
EDIT: I deleted the platforms folder and then downgraded the NS Android runtime with
tns platform add android@6.1.0and it’s working now. Any ideas?@saschaarthur - This is a custom runtime that Shiva (@shiv19) who opened this thread is currently running and he mentioned to me he is no longer seeing this issue, which originally I thought was AWESOME, what was changed so we can get a PR to get it fixed for everyone! 😀 So, I finally had a chance to go through the changes, and it was my whole point I was pointing out, is that the issue is still happening to his customers, it is just is masked.
Please note; Richard, has done other really good work; and some of his changes are actually in the runtimes and have stabilized other issues. But this was a whole new set of patches as he was trying to eliminate some “misc” type random errors… He went a little bit too far in this case, and as such I’m sure his google dashboard looked awesome for the number of errors he was seeing, but his customers would be actually seeing it quit out w/o any logging for a whole range of issues…
As @saschaarthur mentioned this would be really helpful 👍
@NathanaelA @saschaarthur
I have been able to narrow it further down. I compared @7ammer’s plugin list with our own, the only overlapping plugins are:
The issue arises with nativescript-local-notifications. To reproduce please follow the steps below:
Restart device
You should see the reported crash. It happens with nativescript >= 6.2.
@all Are you also using the nativescript-local-notifications plugin?
deleted mine, to not confuse anyone else
@shiv19 ok sorry looked at the last message! Sorry