Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upcom.tns.NativeScriptException - MetaData cannot be opened. #1546
Comments
|
Duplicate of this issue i think NativeScript/NativeScript#8037 and it should contain a fix too |
|
@farfromrefug what I reported is different from what @maxorlovsky reported here. |
|
@shiv19 ok sorry looked at the last message! Sorry |
|
deleted mine, to not confuse anyone else |
|
I have same issue. |
|
I have the same issues. The crash rate is at alarm rate. |
|
Do you use crashlytics or something similar, so that we can get more information about the exception as the message is missing here and we don't know what is the exact error? |
|
We does have Crashlytics. But these crash does not display on Crashlytics, these crash is new, after we upgrade the app from Nativescript 6.1.2 to Nativescript 6.3.0. Only appear on Google Play Console. Some of our user report the app crash at the first time after upgrade, but working fine after that. Not sure this can give us any hint. |
|
Exactly the same for me. |
|
Was anyone able to solve that? |
|
Getting the same error stack after updating last week. 6,491 reports so far! Our project jumped from: Crashalytics is not reporting these errors. In-fact the crash rate on Crashlytics went down! |
|
Perhaps it maybe helpful if we provided more detailed info on our projects?
|
|
@anmaitrannguyen - can you 100% confirm the issue started when you jumped from 6.1.2 (Do you know which specific versions of core modules & runtime in the 6.1.2 set you used before it started crashing) Nailing down the exact point it started is critical in trying to figure out what change could have caused this issue, since the log is non-existent. I assume based on this issue and the other issue in the runtime that nobody has been able to duplicate it locally; just clients and seeing your error count on the nice dashboard. One possible idea on how to duplicate it locally;
You might need to Install doing a sideload and double clicking on APK you manually uploaded to your phone, DO NOT USE If using sideload method doesn't work to duplicate it, deinstall the app; create a beta test of your app; upload GOOD version, have phone join the beta test; and download it. Then do another beta with the "broken" version so that you phone downloads and installs it from Google; rinse and repeat a few times to see if you can cause the error to occur on your device. Specific questions we need to answer:
If some of you can try releasing a new "minor" fix of your app using:
If we can isolate the version of the change, we can figure out what change was introduced and then figure out why it is causing the crash... |
|
@jessorlisa @jpierront @7ammer @shiv19 @anmaitrannguyen @Jmchemama @saschaarthur Ok, I've started a spreadsheet; it would be very helpful if you can all fill in the details for your app here: And if any of you can do testing of your app with 6.1 and/or 6.2 to see if we can narrow down where the issue occurred that would also be super! |
|
Hello, After further investigation we were able to reproduce it. Last stable version is 6.1.2.
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): |
|
@saschaarthur - Awesome; hopefully that is the exact same error; as the line number is different for the handleBindApplication line. However that could be because the first several errors was from 6.4/6.5 and I assume your error was from a 6.2? (hopefully), but the call stack is pretty darn close if it isn't the same error. So I think we should proceed as if it is.
Does the error only occur right after a reboot?
|
|
Ok, I'm 100% sure this is the same error. Guess I'm more tired than I thought I was -- I was reading the wrong stack. The bottom callstack is the NS callstack and it matches 100%... Good job finding the error! That actually isolates it down a lot. I'm going to try your steps even though they don't make a lot of sense on my Android 10 test device and see if I can get the same error... |
|
Its happens when the system is shutting down (and the app is open), not when its booting up. We reproduced it with multiple real devices. Yeah everything 6.2 and higher is affected |
|
@saschaarthur - Ok, I must be doing something wrong. I created a So a fresh 6.5.x app is deployed to my Android 10 device. How frequently do you see a crash? |
|
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? |
As @saschaarthur mentioned this would be really helpful |
every reboot
deployed to device via CLI
Debug version is enough As @jessorlisa wrote already its prob the plugin we also installed, try her commands to reproduce it. |
|
Thanks for the steps -
In addition I had a friend try the same steps on his Android 10 device, and no crash for any run at all... However, since it is Local Notifications plugin, this would easily explain how/why the crash is occurring, this also makes a lot more sense as to how you can duplicate it on a reboot too. My package.json looks like this: Specifics: So can you tell me exactly which phones you have duplicated this using the simple steps of (reboot) So maybe we can track down one of these devices. |
|
@NathanaelA can you please send us a zip file of your testcrash app so that we can see how you're using the local notifications plugin? |
|
@shiv19 - Not even using it. Just creating a new dummy app (no code changes); adding the local notification plugin. So it is a dependency so it is linked in and will activate the two BOOT rules, which I suspect the part of the issue that people can duplicate the issue with. :-) However, in case actual notifications are an issue; I ALSO cloned Eddy's local notification app, upgraded it to 6.5 also and also tried using that both triggering the 1 minute rule (so it triggers a new notification automatically every minute) and the single and multi-notification rule. Rebooted before and after multi-notification ran. Rebooted before and after 1 minute rule ran, also let phone sit for a while just to make sure.... Tried pretty much every variation I can think of with both my Android 9 & Android 10 phones, and had a friend try it also, both the simple empty app and the local notification. None of the three devices did the issue ever appear. However, based on the captured callstack AND assuming it is duplicatable when you add Local-Notifications on some of the phones -- then I'm 99% sure I understand WHY it is failing; just not 100% sure what actually changed to cause it. So duplicating this would allow me to rebuild the runtime with some additional logging to verify my theory and then to trace down how to fix this issue... Also as a small aside the patches Richard did to "fix" the issue are exactly what I expected would happen, and why I mentioned those are very unsafe changes to the runtime. Based on the issue, your customers are actually still crashing just as frequently; you just don't know about it at all now... At this point, based on the awesome data the community has so far provided -- it is very likely they are crashing either when they get a notification (hopefully the notification is still showing and not lost) or when the user clicks on a notification. Personally, based on my knowledge of Android I tend to think it is more likely the app is crashing out when they tap on the notification OR when a Firebase push message occurs and it is then sent to a local notification. Both of those I believe need the JS side of the engine to work; and so either one of them would launch the engine and then could cause the crash with the callstack we are seeing... |
|
I have been able to reproduce it on a Pixel 4, latest Android 10 version. |
Notifications themself are not an issue. It is enough to add the plugin via |
|
Sorry thats very odd, we never tried the emulator and it seems we unluckely tested on all devices which were affected. Heres a List of affected devices we collected so far:
We tested mostly one OnePlus5T and Note 10 (fully updated). Could you please also explain what 'Richard' did (link to commit?) , and who he is here? Maybe he can join the Thread as well?.. |
|
Just tried the crash steps on a Oneplus6: |
|
Just so you are aware, I have cleaned up the issue and hide comments (including some of mine As for status of this;
@Peterf89 & @neil-119 Do you have a callstack, and/or can you confirm you are using the Local-notifications plugin? |
|
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:
|
|
Thank you @NathanaelA for looking into this :) I'm curious to know if there has been any progress. Did you manage to replicate the issue on the pixel phone you ordered? |
|
I've just taken another look at all my crash reports after making a few updates and have noticed this new error. It has only happened twice in comparison to the other error but it looks very similar as it follows the same/similar stack trace and mentions |
|
I got rid of the crashes btw by downgrading NS Android runtime to android@6.1.0 as suggested by Neill and then in return I got a lot of ANRs :( |
|
@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. :) |
|
Hi guys, Update, I have the pixel 4. Yay! Started playing with this issue last night HOWEVER I am still unable to make it fail using the steps. I did a factory reset late last night and am in the process of installing all the updates today as @jessorlisa mentioned here #1546 (comment) that she duplicated it using the latest updates on a Pixel 4. Can anyone tell me if:
I honestly do not think 4-6 should matter; but there has got to be some reason I can't duplicate this on any of my Android 9/10 phones... I did manage to create a different crash on the device (not using NativeScript, one of Googles apps I found an accidental crash in, so I know that the |
|
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!!! |
|
awesome looking forward for the PR of the fix :)
|
|
@NathanaelA Have you already found out what is causing the crashes in combination with the lock screen? |
|
Sorry, I have been really swamped with getting ready to move. But my plan is to see if I can have it fixed by this weekend. :-) |
|
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:
Sounds cool huh?
So the end results after much testing is: Device Unlocked at startup: Device Locked at startup: 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 you are legendary <3 |
|
Very awesome that you found and solved this! Will try it against our app as soon as i figured out how to patch our nativescript runtime with your fix in our build cycle :) |
|
@NathanaelA! That is some Sherlock level deduction there! :) Well done and thank you for all your effort! |
|
@NathanaelA Thanks for all your efforts on this matter. Any chance the fix will be part of the next runtime release? Or is there any latest development version I can install to test? |
|
@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. |
|
Just released 6.5.2 of the android runtime. Sorry for the massive delay; way too many things interrupted me... We'll see if we can get the CI & release system fixed on the Android runtimes so that it isn't a manual pain to get published. |
|
Just updated to 6.5.2, sadly ../testcrash/platforms/android/build-tools/buildMetadata.log: Steps to reproduce: Is there anything else that needs to be updated? |
|
Can fully confirm, that all our pipelines turned red after updating to the latest ns runtime.. It should be very fast fixed / the release should be rollbacked, otherwise i see a flood of issues created.. The release should have been blocked by a working CI system (#1623). Anyways the reason for this seems to be: https://jira.mongodb.org/browse/JAVA-2559 |
|
Yep, it does look like the issues is a Java 8 vs Java 9+ issues (Oracle had a breaking change apparently between 8 & 9). And the CI system would NOT have caught this, unless we had a CI on Java 8 as the build occurred on a newer Java 9+ system and the code runs FINE on Java 9+. I apologize; running this locally worked perfectly for me and others I had do tests, so it slipped thru the cracks. But this does point out that we should have a CI running Java 8, so that we can catch any of these types of issues before they go out. |
|
@saschaarthur @jessorlisa - I have released a v6.5.3 that fixes the metadata building issue on Java 8. Sorry about the issues! |
No worries, thanks for all the affort you put into nativescript! Im just curious and im wondering.. we didnt upgrade any java version at all, also the breaking line is nothing new and inplace since 2019 or so.. So java version seems to be selected during the build process, hows this working for you and the others but for us it didnt? |
Your OS uses whatever your default Java is to run the metadata generator .jar file. When I built the new Android runtime, it also builds the metadata generator .jar file from the .java files (and a couple other jar's), so they were all compiled under Java 9+. I was originally trying to get CI up to build it; but decided to finally just push the copy I built on my machine since I was already over a week since I fixed the actual bug. I really hated leaving you all hanging since I had the fix... So when it created the .jar file one line of code does something different in Java 9+ than Java 8. So when Java 8 was running it; it failed because the resulting variable was different than it could understand properly. So the fix was to cast this variable back to what Java 8 expects (i.e. the base class type which is what Java 8 expects); because Java 8 & Java 9+ both can use the variable as the base type properly everything continues to work even when compiled under later versions of Java. My goal is to try and get the CI up for building @Release and @next versions quickly; so that this becomes an automated process and we can by default only install Java 8 so that it stays fully compatible with all versions of Java by default... |
|
@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. |
Been seeing this crash report at an alarming rate lately
