Android-runtime: com.tns.NativeScriptException - MetaData cannot be opened.

Created on 1 Dec 2019  ·  80Comments  ·  Source: NativeScript/android-runtime

Been seeing this crash report at an alarming rate lately
image
image
image

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)
picture shiv19
👍4

Most helpful comment

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:

  • The Local Notification plugin has a bootup receiver notification, but not just ANY phone bootup receiver notification, but the newer Android 7 bootup receiver notification even if phone is still locked ultra secure version 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? :grinning: In DIRECT_BOOT the 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 a DIRECT_BOOT receiver 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.

  • When this receiver is triggered the receiver code loads and does what it is supposed to; however it is also triggering the native side of the NativeScript app to also boot. So when that part attempts to boot, it fails. It has no access to its files and the metadata is the first set of files it attempts to load. However, in all reality this part of the code does NOT need to actually run when the receiver is triggered at bootup. Unfortunately, The OS doesn't know any better, so it just triggers it (or at least that appears to be what is triggering it) when it fired the receiver.

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...

picture NathanaelA on 21 Jun 2020
🎉5 ❤2 👍2 🚀1

All 80 comments

Duplicate of this issue i think https://github.com/NativeScript/NativeScript/issues/8037 and it should contain a fix too

farfromrefug picture farfromrefug on 2 Dec 2019

@farfromrefug what I reported is different from what @maxorlovsky reported here.

shiv19 picture shiv19 on 2 Dec 2019

@shiv19 ok sorry looked at the last message! Sorry

farfromrefug picture farfromrefug on 3 Dec 2019
👍1

deleted mine, to not confuse anyone else

maxorlovsky picture maxorlovsky on 3 Dec 2019
👍1

I have same issue.

Jmchemama picture Jmchemama on 2 Jan 2020

I have the same issues. The crash rate is at alarm rate.

anmaitrannguyen picture anmaitrannguyen on 10 Jan 2020

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?

vtrifonov picture vtrifonov on 10 Jan 2020

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.
java.lang.RuntimeException: at android.app.ActivityThread.handleBindApplication (ActivityThread.java:6276) at android.app.ActivityThread.access$1200 (ActivityThread.java:238) at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1794) at android.os.Handler.dispatchMessage (Handler.java:106) at android.os.Looper.loop (Looper.java:214) at android.app.ActivityThread.main (ActivityThread.java:7099) 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:19) at android.app.Instrumentation.callApplicationOnCreate (Instrumentation.java:1158) at android.app.ActivityThread.handleBindApplication (ActivityThread.java:6271)

anmaitrannguyen picture anmaitrannguyen on 10 Jan 2020

Exactly the same for me.
It seems that it appeared when switching to NativeScript 6.2. (But I didn't change only that dependency with this update)
This seems to happen only on Android 9 and 10.

jpierront picture jpierront on 25 Jan 2020

Was anyone able to solve that?

jessorlisa picture jessorlisa on 21 Apr 2020

Getting the same error stack after updating last week. 6,491 reports so far! 😬

Our project jumped from:
"tns-core-modules": "^6.0.0" to "^6.5.1",
"tns-android": "6.0.0" to "6.5.0"
"tns-ios": "6.0.1" to "6.5.0"

Crashalytics is not reporting these errors. In-fact the crash rate on Crashlytics went down!

7ammer picture 7ammer on 26 Apr 2020

Perhaps it maybe helpful if we provided more detailed info on our projects?

  • "tns --version": "6.5.0"
  • "tns-core-modules": "6.5.1"
  • framework: "vue"
  • tns-ios: "6.5.0"
  • tns-android: "6.5.0"
"dependencies": {
  "@vue/devtools": "^5.0.6",
  "nativescript-advanced-webview": "^3.0.2",
  "nativescript-animated-circle": "^1.2.0",
  "nativescript-datetimepicker": "^1.2.1",
  "nativescript-dev-appium": "^6.1.3",
  "nativescript-local-notifications": "^4.1.5",
  "nativescript-localstorage": "^2.0.0",
  "nativescript-permissions": "^1.2.3",
  "nativescript-plugin-firebase": "^10.3.0",
  "nativescript-social-share": "^1.5.2",
  "nativescript-socketio": "^3.2.1",
  "nativescript-statusbar": "^5.0.0",
  "nativescript-toasty": "^3.0.0-alpha.2",
  "nativescript-vue": "^2.6.0",
  "nativescript-vue-devtools": "^1.2.0",
  "nativescript-webview-interface": "^1.4.3",
  "tns-core-modules": "^6.5.1",
  "url-parse": "^1.4.7",
  "util-inspect": "^0.1.8"
},
"devDependencies": {
  "@babel/core": "^7.0.0",
  "@babel/preset-env": "^7.0.0",
  "@types/chai": "~4.1.7",
  "@types/mocha": "~5.2.5",
  "@types/node": "^12.12.16",
  "babel-loader": "^8.0.2",
  "chai": "~4.1.2",
  "mocha": "~5.2.0",
  "mocha-junit-reporter": "~1.18.0",
  "mocha-multi": "~1.0.1",
  "mochawesome": "~3.1.2",
  "nativescript-dev-webpack": "^1.0.0",
  "nativescript-vue-template-compiler": "^2.5.0",
  "nativescript-worker-loader": "^0.11.0",
  "node-sass": "^4.9.2",
  "tns-platform-declarations": "^6.0.0",
  "typescript": "^3.2.4",
  "vue": "^2.5.22",
  "vue-loader": "^15.4.0"
}
7ammer picture 7ammer on 27 Apr 2020

@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;

  1. Deinstall the app on your android 9/10 phone. (Make sure you are on Android 9 or 10!)
  2. Install the Prior version RELEASE (working) version (what you uploaded to Google!)
  3. Install the new version (again what you uploaded to Google!)
    (It would be much better for your test if you re-use what you originally uploaded to Google; because tooling changes the APK, if you rebuild your 6.1 version using the 6.5 tooling your app could be slightly different)

You might need to Install doing a sideload and double clicking on APK you manually uploaded to your phone, DO NOT USE ADB to install, you can use ADB to copy it to the phone; but lets try and make this as close to what would happen with a client and make the phone do all the work.

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:

  1. Which specific version of Android Runtime and Core was the issue introduced
  2. Are any/all apps using Workers?

If some of you can try releasing a new "minor" fix of your app using:

  • [ ] Android 6.2.0 w/ Core 6.2.0 (Earliest 6.2)
  • [ ] Android 6.2.0 w/ Core 6.2.3 (Latest 6.2)
  • [ ] Android 6.1.0 w/ Core 6.1.0 (Earliest 6.1)
  • [ ] Android 6.1.2 w/ Core 6.1.2 (Latest 6.1)

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...

NathanaelA picture NathanaelA on 27 Apr 2020

@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:
https://docs.google.com/spreadsheets/d/1qU-H3Kp-OGCmRffvfw4IejSDwpf5Un7bq-sR8XoL_X8/edit?usp=sharing

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!

NathanaelA picture NathanaelA on 29 Apr 2020

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:

  • Open your app (version> 6.1.2).
  • run "adb logcat --buffer=crash" (stacktrace logging, optional)
  • Reboot your device
  • run "adb logcat --buffer=crash" (stacktrace logging, optional)

we were able to fetch a full stacktrace like this with following error message:

04-30 12:12:38.665  3354  3354 E AndroidRuntime: FATAL EXCEPTION: main
04-30 12:12:38.665  3354  3354 E AndroidRuntime: Process: com.xxx.mobile, PID: 3354
04-30 12:12:38.665  3354  3354 E AndroidRuntime: java.lang.RuntimeException: Unable to create application com.tns.NativeScriptApplication: com.tns.NativeScriptException: metadata folder couldn't be opened!
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6079)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at android.app.ActivityThread.access$1300(ActivityThread.java:207)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1758)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:106)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:193)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at android.app.ActivityThread.main(ActivityThread.java:6898)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at java.lang.reflect.Method.invoke(Native Method)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:537)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
04-30 12:12:38.665  3354  3354 E AndroidRuntime: Caused by: com.tns.NativeScriptException: metadata folder couldn't be opened!
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at com.tns.Runtime.initNativeScript(Native Method)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at com.tns.Runtime.init(Runtime.java:627)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at com.tns.Runtime.init(Runtime.java:601)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at com.tns.Runtime.initRuntime(Runtime.java:591)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at com.tns.Runtime.initializeRuntimeWithConfiguration(Runtime.java:566)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at com.tns.RuntimeHelper.initRuntime(RuntimeHelper.java:163)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at com.tns.NativeScriptApplication.onCreate(NativeScriptApplication.java:19)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1165)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6074)
04-30 12:12:38.665  3354  3354 E AndroidRuntime:        ... 8 more

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):

04-30 12:52:18.004  7977  7977 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x572 in tid 7977 (om.xxx.mobile), pid 7977 (om.xxx.mobile)
04-30 12:52:18.109  8026  8026 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
04-30 12:52:18.109  8026  8026 F DEBUG   : Build fingerprint: 'samsung/d2seea/d2s:10/QP1A.190711.020/N975FXXU3CTC9:user/release-keys'
04-30 12:52:18.110  8026  8026 F DEBUG   : Revision: '24'
04-30 12:52:18.110  8026  8026 F DEBUG   : ABI: 'arm64'
04-30 12:52:18.111  8026  8026 F DEBUG   : Timestamp: 2020-04-30 12:52:18+0200
04-30 12:52:18.111  8026  8026 F DEBUG   : pid: 7977, tid: 7977, name: om.xxx.mobile  >>> com.xxx.mobile <<<
04-30 12:52:18.111  8026  8026 F DEBUG   : uid: 10390
04-30 12:52:18.111  8026  8026 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x572
04-30 12:52:18.111  8026  8026 F DEBUG   : Cause: null pointer dereference
04-30 12:52:18.111  8026  8026 F DEBUG   :     x0  00000000d2801168  x1  0000000000000572  x2  0000007fe6bfa300  x3  0000000000000571
04-30 12:52:18.111  8026  8026 F DEBUG   :     x4  0000000000000000  x5  0000000000000000  x6  0000007910a89200  x7  0000007910a89000
04-30 12:52:18.111  8026  8026 F DEBUG   :     x8  0000000000000000  x9  0000000000000001  x10 0000000000004001  x11 0000000000000000
04-30 12:52:18.111  8026  8026 F DEBUG   :     x12 0000000000000000  x13 0000000000000000  x14 ffffffffffffffff  x15 00000000000000e0
04-30 12:52:18.111  8026  8026 F DEBUG   :     x16 0000007a020c6160  x17 0000007a08bfb3f8  x18 0000007a082fc000  x19 0000007fe6bfac10
04-30 12:52:18.111  8026  8026 F DEBUG   :     x20 0000007fe6bfa850  x21 0000000000000000  x22 0000007fe6bfac10  x23 00000000ffffffff
04-30 12:52:18.111  8026  8026 F DEBUG   :     x24 00000079118415c8  x25 0000000000000000  x26 0000007a077700b0  x27 0000000000000001
04-30 12:52:18.111  8026  8026 F DEBUG   :     x28 0000007fe6bfcb20  x29 0000007fe6bfa330
04-30 12:52:18.111  8026  8026 F DEBUG   :     sp  0000007fe6bfa330  lr  000000791173a6f4  pc  000000791173a708
04-30 12:52:18.115  8026  8026 F DEBUG   :
04-30 12:52:18.115  8026  8026 F DEBUG   : backtrace:
04-30 12:52:18.115  8026  8026 F DEBUG   :       #00 pc 0000000000cb1708  /data/app/com.xxx.mobile-XVZOEoQhsGUe5MfcemPIxw==/lib/arm64/libNativeScript.so (BuildId: c32f555a4cc76af68f68df53be8a35d41f5938eb)
04-30 12:52:18.115  8026  8026 F DEBUG   :       #01 pc 0000000000cb26b0  /data/app/com.xxx.mobile-XVZOEoQhsGUe5MfcemPIxw==/lib/arm64/libNativeScript.so (_Unwind_RaiseException+112) (BuildId: c32f555a4cc76af68f68df53be8a35d41f5938eb)
04-30 12:52:18.115  8026  8026 F DEBUG   :       #02 pc 00000000008c69ac  /data/app/com.xxx.mobile-XVZOEoQhsGUe5MfcemPIxw==/lib/arm64/libNativeScript.so (__cxa_throw+112) (BuildId: c32f555a4cc76af68f68df53be8a35d41f5938eb)
04-30 12:52:18.115  8026  8026 F DEBUG   :       #03 pc 000000000028e7e4  /data/app/com.xxx.mobile-XVZOEoQhsGUe5MfcemPIxw==/lib/arm64/libNativeScript.so (BuildId: c32f555a4cc76af68f68df53be8a35d41f5938eb)
04-30 12:52:18.115  8026  8026 F DEBUG   :       #04 pc 0000000000000572  <unknown>
saschaarthur picture saschaarthur on 1 May 2020
👍2

@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.

  1. Can you duplicate this on multiple devices, or only a specific device? Which one(s)?
  2. Does it occur on an emulator; or only a real device?
  3. So everything 6.2 and higher, 6.2 runtime or 6.2 core, or specifically the latest 6.2.x versions?

Does the error only occur right after a reboot?

  1. Do you do anything else; or is it when Android creates the "open" list from all the open apps after a restart?
  2. Or is it when you restart the app from the menu; or start the app from the open apps list?
NathanaelA picture NathanaelA on 1 May 2020

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...

NathanaelA picture NathanaelA on 1 May 2020

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 picture saschaarthur on 1 May 2020

@saschaarthur - Ok, I must be doing something wrong. :grinning:

I created a
tns create testcrash --js
cd testcrash
tns run android

So a fresh 6.5.x app is deployed to my Android 10 device.
type
adb logcat --buffer=crash
Restart the device, unlock device.
adb logcat --buffer=crash
And no crash...

How frequently do you see a crash?
Do you have to have a version released from the Play Store, or can it be deployed to the device from the CLI?
Can it be a debug version, or are you testing only signed apps?

NathanaelA picture NathanaelA on 1 May 2020

@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:

  • nativescript-local-notifications
  • nativescript-plugin-firebase

The issue arises with nativescript-local-notifications. To reproduce please follow the steps below:

tns create testcrash --js
cd testcrash
tns plugin add nativescript-local-notifications
tns run android
adb logcat --buffer=crash

Restart device

adb logcat --buffer=crash

You should see the reported crash. It happens with nativescript >= 6.2.

@all Are you also using the nativescript-local-notifications plugin?

jessorlisa picture jessorlisa on 2 May 2020
👍1

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..

As @saschaarthur mentioned this would be really helpful 👍

jessorlisa picture jessorlisa on 2 May 2020
👍1

How frequently do you see a crash?

_every_ reboot

Do you have to have a version released from the Play Store, or can it be deployed to the device
from the CLI?

deployed to device via CLI

Can it be a debug version, or are you testing only signed apps?

Debug version is enough

As @jessorlisa wrote already its prob the plugin we also installed, try her commands to reproduce it.

saschaarthur picture saschaarthur on 2 May 2020

@jessorlisa, @saschaarthur -

Thanks for the steps -
Either I am blessed with incredibly stable phones, or we are still missing something...

  1. I tried it on my Android 10 and Android 9 device.
  2. I tried it on a Android 10 emulator
  3. I also cloned the Local Notification and installed his demo-js app on both Android 9 & 10 and still no crashes... Even after having rebooting while notifications were active...
  4. I tried the (4.2.1 & 4.1.5) of Local Notification plugin just to see if anything changed in his plugin that could be affecting it.

In addition I had a friend try the same steps on his Android 10 device, and no crash for any run at all...

:frowning_face:

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:

{
  "nativescript": {
    "id": "org.nativescript.testCrash",
    "tns-android": {
      "version": "6.5.0"
    },
    "tns-ios": {
      "version": "6.5.0"
    }
  },
  "dependencies": {
    "@nativescript/theme": "~2.3.3",
    "nativescript-local-notifications": "4.1.5",
    "tns-core-modules": "~6.5.0"
  },
  "devDependencies": {
    "nativescript-dev-webpack": "~1.5.1"
  }}

Specifics:
NS-Core = 6.5.1
NS-Local-Notification = 4.2.1

So can you tell me exactly which phones you have duplicated this using the simple steps of 

tns create testcrash --js
cd testcrash
tns plugin add nativescript-local-notifications
tns run android
adb logcat --buffer=crash   <---  This actually shouldn't be needed; before reboot

(reboot)
adb logcat --buffer=crash

So maybe we can track down one of these devices.

NathanaelA picture NathanaelA on 2 May 2020

@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 picture shiv19 on 3 May 2020

@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...

NathanaelA picture NathanaelA on 3 May 2020

I have been able to reproduce it on a _Pixel 4, latest Android 10 version_.
Sadly it does not seem to be happening on any emulator I have tested.

jessorlisa picture jessorlisa on 3 May 2020

However, in case actual notifications are an issue;

Notifications themself are not an issue. It is enough to add the plugin via tns plugin add nativescript-local-notifications - without any implementation.

jessorlisa picture jessorlisa on 3 May 2020
👍2

Sorry thats very odd, we never tried the emulator and it seems we unluckely tested on all devices which were affected.
We didnt saw a pattern (and still dont see any) but it seems theres is one..?

Heres a List of affected devices we collected so far:

grafik

We tested mostly one OnePlus5T and Note 10 (fully updated).
Maybe its also related to device settings? Is there a possibility of a settings dump we could provide you?

Could you please also explain what 'Richard' did (link to commit?) , and who he is here? Maybe he can join the Thread as well?..

saschaarthur picture saschaarthur on 3 May 2020

Just tried the crash steps on a Oneplus6:

tns create crashtest --js
cd crashtest
tns plugin add nativescript-local-notifications
tns run android (not needed if app is already on device)
adb logcat --buffer=crash (not needed but can be useful)
[REBOOT]
adb logcat --buffer=crash (see result below)

[13:09:02] ~ 🤜 adb logcat --buffer=crash
05-03 13:09:42.492  3208  3208 F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 3208 (init), pid 3208 (init)
05-03 13:09:42.540  3208  3208 F libc    : crash_dump helper failed to exec
05-03 13:09:44.236  3490  3490 E AndroidRuntime: FATAL EXCEPTION: main
05-03 13:09:44.236  3490  3490 E AndroidRuntime: Process: org.nativescript.crashtest, PID: 3490
05-03 13:09:44.236  3490  3490 E AndroidRuntime: java.lang.RuntimeException: Unable to create application com.tns.NativeScriptApplication: com.tns.NativeScriptException: metadata folder couldn't be opened!
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6652)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at android.app.ActivityThread.access$1600(ActivityThread.java:231)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1952)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at android.os.Handler.dispatchMessage(Handler.java:107)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at android.os.Looper.loop(Looper.java:214)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at android.app.ActivityThread.main(ActivityThread.java:7682)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at java.lang.reflect.Method.invoke(Native Method)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:516)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:950)
05-03 13:09:44.236  3490  3490 E AndroidRuntime: Caused by: com.tns.NativeScriptException: metadata folder couldn't be opened!
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at com.tns.Runtime.initNativeScript(Native Method)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at com.tns.Runtime.init(Runtime.java:627)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at com.tns.Runtime.init(Runtime.java:601)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at com.tns.Runtime.initRuntime(Runtime.java:591)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at com.tns.Runtime.initializeRuntimeWithConfiguration(Runtime.java:566)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at com.tns.RuntimeHelper.initRuntime(RuntimeHelper.java:163)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at com.tns.NativeScriptApplication.onCreate(NativeScriptApplication.java:19)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1197)
05-03 13:09:44.236  3490  3490 E AndroidRuntime:    at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6647)
7ammer picture 7ammer on 3 May 2020

This is what the app looks like after a reboot and before I open it.

When I click on the app it simply shows the splash screen with no visual error message. At least it's not crashing while it's being used.
WhatsApp Image 2020-05-03 at 13 41 23

7ammer picture 7ammer on 3 May 2020

Has anyone noticed an increase in crashes on iOS?

7ammer picture 7ammer on 3 May 2020

Could you please also explain what 'Richard' did (link to commit?) , and who he is here? Maybe he can join the Thread as well?..

The Richard note was actually for Shiva; he did some work with nStudio and he add some additional try/catches in the android runtime to try and harden the runtime to eliminate crashes. However, when Shiva shared his patches with me the other day I looked through them and realized they would most certainly catch a number of errors; but then NS would just exit out, without logging anything at all. Leaving the user a "Crashed" experience but no visible crash log to google or anywhere else; just a hidden crash.

So because Shiva is running this modified runtime, I was letting him know the issue still exists in it -- it is just masked and he never sees it anyplace. I was just warning him about that... :-D

Now as to the actual issue; I'm 99% sure that all of your user are not reporting this crash because of a reboot. This is more likely that the users are seeing the same issue when the app is suspended because they went to play a game (opened facebook, or some other large app that caused the OS to swap your app out of memory), then they clicked a notification or maybe even when they brought up the list of running app; it triggers the same code path as you have discovered when you reboot the phone -- as the app is also in a "paged out" state on reboot...

Sounds like I need to order a OneTouch 5T or 6T to see if I can track this down.

I actually tried switching a huge number of settings on my Android 10 device; just to see if I could cause it to fail -- So not sure if I can think of any other settings that would make any sense. The only thing I can think of is that the launcher on my android 10 and android 9 devices are the using same Samsung launcher and so they have something in it on these two devices that is mitigating it unintentionally.

NathanaelA picture NathanaelA on 3 May 2020

He did some work with nStudio and he add some additional try/catches in the android runtime to try and harden the runtime to eliminate crashes. However, when Shiva shared his patches with me the other day I looked through them and realized they would most certainly catch a number of errors; but then NS would just exit out, without logging anything at all.

This is really really bad and shouldnt be like that. Try catch ignore is never a good idea and will end in very weird situations nobody will understand..
Even if its a bit offtopic, do you mind to share the places where this happens ? Im curious..

saschaarthur picture saschaarthur on 4 May 2020

@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! :grinning: 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...

NathanaelA picture NathanaelA on 4 May 2020
👍1

@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! :grinning: 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...

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.

shiv19 picture shiv19 on 4 May 2020
👍2 🎉1

It seems I got the exact same issue on my newest build, which is odd, is that I previously made a perfectly working release with 6.2.0, a week ago... Today I tried with 6.2.0 and 6.5.0 android runtime, and I'm getting the issue on all the phones I can test on.

If I do not build the release with --env.snapshotInDocker and --env.snapshot, it's working perfectly fine (except longer startup time).

Here is the crash log :

05-05 20:04:18.979  2423  2423 E AndroidRuntime: FATAL EXCEPTION: main
05-05 20:04:18.979  2423  2423 E AndroidRuntime: Process: fr.wikodit.xxxxx, PID: 2423
05-05 20:04:18.979  2423  2423 E AndroidRuntime: java.lang.RuntimeException: Unable to instantiate activity ComponentInfo{fr.wikodit.xxxxx/com.tns.NativeScriptActivity}: com.tns.NativeScriptException: Failed to create JavaScript extend wrapper for class 'com/tns/NativeScriptActivity'
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2850)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3059)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at android.app.ActivityThread.-wrap11(Unknown Source:0)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1724)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at android.os.Handler.dispatchMessage(Handler.java:106)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at android.os.Looper.loop(Looper.java:164)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at android.app.ActivityThread.main(ActivityThread.java:7000)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at java.lang.reflect.Method.invoke(Native Method)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:441)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1408)
05-05 20:04:18.979  2423  2423 E AndroidRuntime: Caused by: com.tns.NativeScriptException: Failed to create JavaScript extend wrapper for class 'com/tns/NativeScriptActivity'
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at com.tns.Runtime.createJSInstanceNative(Native Method)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at com.tns.Runtime.createJSInstance(Runtime.java:820)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at com.tns.Runtime.initInstance(Runtime.java:793)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at com.tns.NativeScriptActivity.<init>(NativeScriptActivity.java:13)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at java.lang.Class.newInstance(Native Method)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at android.app.Instrumentation.newActivity(Instrumentation.java:1181)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2840)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:    ... 9 more

Working:

tns build android --bundle --release --env.release --env.production --env.aot

Not Working:

tns build android --bundle --release --env.snapshotInDocker --env.snapshot  --env.release --env.production --env.aot

I also noticed something else, I compared the code diff, between previous week and now, and nothing changed (even within the package-lock). However the working aab release previous week was around 13/15mb, and the current (snapshoted, and not working) release is only around 9/11mb. No code has been removed, rather some code has been added, and no plugins or packages have been added or removed.

The only thing I can think of, is that I pruned docker images/containers within the week. (even that I'm not sure of)

Edit:
Does not seems to belongs here, sorry I misplaced it in the wrong thread.
Fyi, using a linux and not a docker snapshot made the build worked

Tronix117 picture Tronix117 on 5 May 2020

Hi,
I'm getting the Exception 'com.tns.NativeScriptException: metadata folder couldn't be opened!' on a Samsung S7 with Android 8.0 (SDK 26) with Release 6.5.0.
This might be the same Issue.
I'll try with an earlier Release.

ptrxwsmitt picture ptrxwsmitt on 5 May 2020

It seems I got the exact same issue on my newest build, which is odd, is that I previously made a perfectly working release with 6.2.0, a week ago... Today I tried with 6.2.0 and 6.5.0 android runtime, and I'm getting the issue on all the phones I can test on.

If I do not build the release with --env.snapshotInDocker and --env.snapshot, it's working perfectly fine (except longer startup time).

Here is the crash log :

05-05 20:04:18.979  2423  2423 E AndroidRuntime: FATAL EXCEPTION: main
05-05 20:04:18.979  2423  2423 E AndroidRuntime: Process: fr.wikodit.xxxxx, PID: 2423
05-05 20:04:18.979  2423  2423 E AndroidRuntime: java.lang.RuntimeException: Unable to instantiate activity ComponentInfo{fr.wikodit.xxxxx/com.tns.NativeScriptActivity}: com.tns.NativeScriptException: Failed to create JavaScript extend wrapper for class 'com/tns/NativeScriptActivity'
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2850)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3059)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.app.ActivityThread.-wrap11(Unknown Source:0)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1724)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.os.Handler.dispatchMessage(Handler.java:106)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.os.Looper.loop(Looper.java:164)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.app.ActivityThread.main(ActivityThread.java:7000)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at java.lang.reflect.Method.invoke(Native Method)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:441)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1408)
05-05 20:04:18.979  2423  2423 E AndroidRuntime: Caused by: com.tns.NativeScriptException: Failed to create JavaScript extend wrapper for class 'com/tns/NativeScriptActivity'
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at com.tns.Runtime.createJSInstanceNative(Native Method)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at com.tns.Runtime.createJSInstance(Runtime.java:820)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at com.tns.Runtime.initInstance(Runtime.java:793)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at com.tns.NativeScriptActivity.<init>(NativeScriptActivity.java:13)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at java.lang.Class.newInstance(Native Method)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.app.Instrumentation.newActivity(Instrumentation.java:1181)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2840)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  ... 9 more

_Working:_

tns build android --bundle --release --env.release --env.production --env.aot

_Not Working:_

tns build android --bundle --release --env.snapshotInDocker --env.snapshot  --env.release --env.production --env.aot

I also noticed something odd, I compared the code diff, between previous week and now, and nothing changed (even within the package-lock). However the working aab release previous week was around 13/15mb, and the current (snapshoted, and not working) release is only around 9/11mb. No code has been removed, rather some code has been added, and no plugin or packages have been added or removed.

The only thing I can think of, is that I pruned docker images/containers within the week. (even

It seems I got the exact same issue on my newest build, which is odd, is that I previously made a perfectly working release with 6.2.0, a week ago... Today I tried with 6.2.0 and 6.5.0 android runtime, and I'm getting the issue on all the phones I can test on.

If I do not build the release with --env.snapshotInDocker and --env.snapshot, it's working perfectly fine (except longer startup time).

Here is the crash log :

05-05 20:04:18.979  2423  2423 E AndroidRuntime: FATAL EXCEPTION: main
05-05 20:04:18.979  2423  2423 E AndroidRuntime: Process: fr.wikodit.xxxxx, PID: 2423
05-05 20:04:18.979  2423  2423 E AndroidRuntime: java.lang.RuntimeException: Unable to instantiate activity ComponentInfo{fr.wikodit.xxxxx/com.tns.NativeScriptActivity}: com.tns.NativeScriptException: Failed to create JavaScript extend wrapper for class 'com/tns/NativeScriptActivity'
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2850)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3059)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.app.ActivityThread.-wrap11(Unknown Source:0)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1724)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.os.Handler.dispatchMessage(Handler.java:106)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.os.Looper.loop(Looper.java:164)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.app.ActivityThread.main(ActivityThread.java:7000)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at java.lang.reflect.Method.invoke(Native Method)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:441)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1408)
05-05 20:04:18.979  2423  2423 E AndroidRuntime: Caused by: com.tns.NativeScriptException: Failed to create JavaScript extend wrapper for class 'com/tns/NativeScriptActivity'
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at com.tns.Runtime.createJSInstanceNative(Native Method)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at com.tns.Runtime.createJSInstance(Runtime.java:820)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at com.tns.Runtime.initInstance(Runtime.java:793)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at com.tns.NativeScriptActivity.<init>(NativeScriptActivity.java:13)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at java.lang.Class.newInstance(Native Method)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.app.Instrumentation.newActivity(Instrumentation.java:1181)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2840)
05-05 20:04:18.979  2423  2423 E AndroidRuntime:  ... 9 more

_Working:_

tns build android --bundle --release --env.release --env.production --env.aot

_Not Working:_

tns build android --bundle --release --env.snapshotInDocker --env.snapshot  --env.release --env.production --env.aot

I also noticed something odd, I compared the code diff, between previous week and now, and nothing changed (even within the package-lock). However the working aab release previous week was around 13/15mb, and the current (snapshoted, and not working) release is only around 9/11mb. No code has been removed, rather some code has been added, and no plugin or packages have been added or removed.

The only thing I can think of, is that I pruned docker images/containers within the week. (even that I'm not sure of)

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?

saschaarthur picture saschaarthur on 5 May 2020
👍2

Hi,
I'm getting the Exception 'com.tns.NativeScriptException: metadata folder couldn't be opened!' on a Samsung S7 with Android 8.0 (SDK 26) with Release 6.5.0.
This might be the same Issue.
I'll try with an earlier Release.

By the way I'm getting the error every time that I execute 'tns run android', same for debug.
The same Error Message was also mentioned in https://github.com/NativeScript/android-runtime/issues/1488

ptrxwsmitt picture ptrxwsmitt on 6 May 2020

Hi,
I'm getting the Exception 'com.tns.NativeScriptException: metadata folder couldn't be opened!' on a Samsung S7 with Android 8.0 (SDK 26) with Release 6.5.0.
This might be the same Issue.
I'll try with an earlier Release.

By the way I'm getting the error every time that I execute 'tns run android', same for debug.
The same Error Message was also mentioned in https://github.com/NativeScript/android-runtime/issues/1488

What is your Target API level?

shiv19 picture shiv19 on 6 May 2020

Hi,
I'm getting the Exception 'com.tns.NativeScriptException: metadata folder couldn't be opened!' on a Samsung S7 with Android 8.0 (SDK 26) with Release 6.5.0.
This might be the same Issue.
I'll try with an earlier Release.

By the way I'm getting the error every time that I execute 'tns run android', same for debug.
The same Error Message was also mentioned in #1488

What is your Target API level?

I used a vue template for generating the android part. I found that the target level is 17 inside gradle and android:verionName 1.0 in the manifest. i don't know yet if this shold be euqal. i did not find any way to define the target level in nativescript or a way to let me generate the gradle file and manifest via nativescript.
Testing was just against api level 26 yet.

ptrxwsmitt picture ptrxwsmitt on 6 May 2020

Can you try again with minSdk level 21 and target Sdk as 29?

shiv19 picture shiv19 on 6 May 2020

Can you try again with minSdk level 21 and target Sdk as 29?

Yes, I tried this in the meantime, without any effect.
I also tried other different settings for the minSdk and Target Sdk, also without different results.
I regognized that somehow I got the app installed two times on the phone. Removing did not work from the menu ui, it brought up the stacktrace directly. I was able to remove both apps using the android system settings then.

Finally I recognized I did not have any of the Sdks installed within the sdk manager. As Nativescript did not complain about it, I thought it would not be required.
I installed the sdk for my current test phone (api 26). Now I don't get the stacktrace any more, but i get an error ' has stopped'.
That's how far I got until now.

ptrxwsmitt picture ptrxwsmitt on 7 May 2020

Can you try again with minSdk level 21 and target Sdk as 29?

Found a Stacktrace on the device log...

05-08 12:48:16.042 19797 19797 D AndroidRuntime: Shutting down VM
05-08 12:48:16.045 19797 19797 E AndroidRuntime: FATAL EXCEPTION: main
05-08 12:48:16.045 19797 19797 E AndroidRuntime: Process: org.nativescript.upsteeemr, PID: 19797
05-08 12:48:16.045 19797 19797 E AndroidRuntime: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/org.nativescript.upsteeemr-F6Y_8gZsOXpm63DeHbpE_g==/base.apk"],nativeLibraryDirectories=[/data/app/org.nativescript.upsteeemr-F6Y_8gZsOXpm63DeHbpE_g==/lib/arm64, /system/lib64, /system/vendor/lib64]]] couldn't find "libNativeScript.so"
05-08 12:48:16.045 19797 19797 E AndroidRuntime:    at java.lang.Runtime.loadLibrary0(Runtime.java:1011)
05-08 12:48:16.045 19797 19797 E AndroidRuntime:    at java.lang.System.loadLibrary(System.java:1657)
05-08 12:48:16.045 19797 19797 E AndroidRuntime:    at com.tns.RuntimeHelper.initRuntime(RuntimeHelper.java:70)
05-08 12:48:16.045 19797 19797 E AndroidRuntime:    at com.tns.NativeScriptApplication.onCreate(NativeScriptApplication.java:19)
05-08 12:48:16.045 19797 19797 E AndroidRuntime:    at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1125)
05-08 12:48:16.045 19797 19797 E AndroidRuntime:    at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6062)
05-08 12:48:16.045 19797 19797 E AndroidRuntime:    at android.app.ActivityThread.-wrap1(Unknown Source:0)
05-08 12:48:16.045 19797 19797 E AndroidRuntime:    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1764)
05-08 12:48:16.045 19797 19797 E AndroidRuntime:    at android.os.Handler.dispatchMessage(Handler.java:105)
05-08 12:48:16.045 19797 19797 E AndroidRuntime:    at android.os.Looper.loop(Looper.java:164)
05-08 12:48:16.045 19797 19797 E AndroidRuntime:    at android.app.ActivityThread.main(ActivityThread.java:6944)
05-08 12:48:16.045 19797 19797 E AndroidRuntime:    at java.lang.reflect.Method.invoke(Native Method)
05-08 12:48:16.045 19797 19797 E AndroidRuntime:    at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:327)
05-08 12:48:16.045 19797 19797 E AndroidRuntime:    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1374)
ptrxwsmitt picture ptrxwsmitt on 8 May 2020

libNativeScript.so is not packaged into the .apk.
Wouldn't that be required?

ptrxwsmitt picture ptrxwsmitt on 8 May 2020

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.

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..

saschaarthur picture saschaarthur on 8 May 2020
👍3

libNativeScript.so is not packaged into the .apk.
Wouldn't that be required?

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.

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..

Can you try again with minSdk level 21 and target Sdk as 29?

Found a Stacktrace on the device log...

05-08 12:48:16.042 19797 19797 D AndroidRuntime: Shutting down VM 05-08 12:48:16.045 19797 19797 E AndroidRuntime: FATAL EXCEPTION: main 05-08 12:48:16.045 19797 19797 E AndroidRuntime: Process: org.nativescript.upsteeemr, PID: 19797 05-08 12:48:16.045 19797 19797 E AndroidRuntime: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/org.nativescript.upsteeemr-F6Y_8gZsOXpm63DeHbpE_g==/base.apk"],nativeLibraryDirectories=[/data/app/org.nativescript.upsteeemr-F6Y_8gZsOXpm63DeHbpE_g==/lib/arm64, /system/lib64, /system/vendor/lib64]]] couldn't find "libNativeScript.so" 05-08 12:48:16.045 19797 19797 E AndroidRuntime: at java.lang.Runtime.loadLibrary0(Runtime.java:1011) 05-08 12:48:16.045 19797 19797 E AndroidRuntime: at java.lang.System.loadLibrary(System.java:1657) 05-08 12:48:16.045 19797 19797 E AndroidRuntime: at com.tns.RuntimeHelper.initRuntime(RuntimeHelper.java:70) 05-08 12:48:16.045 19797 19797 E AndroidRuntime: at com.tns.NativeScriptApplication.onCreate(NativeScriptApplication.java:19) 05-08 12:48:16.045 19797 19797 E AndroidRuntime: at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1125) 05-08 12:48:16.045 19797 19797 E AndroidRuntime: at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6062) 05-08 12:48:16.045 19797 19797 E AndroidRuntime: at android.app.ActivityThread.-wrap1(Unknown Source:0) 05-08 12:48:16.045 19797 19797 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1764) 05-08 12:48:16.045 19797 19797 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:105) 05-08 12:48:16.045 19797 19797 E AndroidRuntime: at android.os.Looper.loop(Looper.java:164) 05-08 12:48:16.045 19797 19797 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:6944) 05-08 12:48:16.045 19797 19797 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method) 05-08 12:48:16.045 19797 19797 E AndroidRuntime: at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:327) 05-08 12:48:16.045 19797 19797 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1374)

This is a different thing and its related that you dont build you aab correct, either build it correct (check the logs some part of your builds failing) or remove aab for now. Have a look here, you prob have the same: https://github.com/NativeScript/nativescript-dev-webpack/issues/1134

saschaarthur picture saschaarthur on 8 May 2020

@shiv19 Maybe you could update the issue title to "com.tns.NativeScriptException: metadata folder couldn't be opened!" ?

jessorlisa picture jessorlisa on 8 May 2020

Getting the error again after deleting the platforms folder.

Edit: removed stacktrace, that was leading nowhere.

As it seems the metadata generator is correctly started but is not generating any *.dat files

23:32:57.082 [DEBUG] [org.gradle.api.internal.tasks.execution.DefaultTaskFingerprinter] Fingerprinting property classpath (Classpath) for task ':app:buildMetadata'
23:32:57.082 [INFO] [org.gradle.internal.execution.steps.ResolveCachingStateStep] Caching disabled for task ':app:buildMetadata' because:
  Build cache is disabled
23:32:57.083 [DEBUG] [org.gradle.internal.execution.steps.SkipUpToDateStep] Determining if task ':app:buildMetadata' is up-to-date
23:32:57.083 [INFO] [org.gradle.internal.execution.steps.SkipUpToDateStep] Task ':app:buildMetadata' is not up-to-date because:
  No history is available.
23:32:57.083 [DEBUG] [org.gradle.internal.execution.steps.CreateOutputsStep] Ensuring parent directory exists for property $1$1 at C:\Development\workspaces\private\my-drawer-vue\platforms\android\app\src\main\assets\metadata\treeNodeStream.dat
23:32:57.083 [DEBUG] [org.gradle.internal.execution.steps.CreateOutputsStep] Ensuring parent directory exists for property $1$2 at C:\Development\workspaces\private\my-drawer-vue\platforms\android\app\src\main\assets\metadata\treeStringsStream.dat
23:32:57.083 [DEBUG] [org.gradle.internal.execution.steps.CreateOutputsStep] Ensuring parent directory exists for property $1$3 at C:\Development\workspaces\private\my-drawer-vue\platforms\android\app\src\main\assets\metadata\treeValueStream.dat
23:32:57.083 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter] Executing actions for task ':app:buildMetadata'.
23:32:57.083 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Execute doFirst {} action for :app:buildMetadata' started
23:32:57.086 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Execute doFirst {} action for :app:buildMetadata'
23:32:57.086 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Execute doFirst {} action for :app:buildMetadata' completed
23:32:57.086 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Execute exec for :app:buildMetadata' started
23:32:57.086 [INFO] [org.gradle.process.internal.DefaultExecHandle] Starting process 'command 'C:\Development\tools\java\jdk-8.0_201\bin\java.exe''. Working directory: C:\Development\workspaces\private\my-drawer-vue\platforms\android\build-tools Command: C:\Development\tools\java\jdk-8.0_201\bin\java.exe -Dfile.encoding=windows-1252 -Duser.country=US -Duser.language=en -Duser.variant -jar android-metadata-generator.jar verbose
23:32:57.086 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Environment for process 'command 'C:\Development\tools\java\jdk-8.0_201\bin\java.exe'': {USERDOMAIN_ROAMINGPROFILE=DESKTOP-PHVQKLV, PROCESSOR_LEVEL=6, SESSIONNAME=Console, ALLUSERSPROFILE=C:\ProgramData, PROCESSOR_ARCHITECTURE=AMD64, ANDROID_HOME=C:\Users\Patrick Waldschmitt\AppData\Local\Android\Sdk, PSModulePath=C:\Users\Patrick Waldschmitt\Documents\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules, SystemDrive=C:, DIRNAME=C:\Development\workspaces\private\my-drawer-vue\platforms\android\, USERNAME=Patrick Waldschmitt, CMD_LINE_ARGS=assembleDebug --stacktrace --debug -PcompileSdk=android-29 -PtargetSdk=29 -PbuildToolsVersion=29.0.3 -PgenerateTypings=false, ProgramFiles(x86)=C:\Program Files (x86), APP_HOME=C:\Development\workspaces\private\my-drawer-vue\platforms\android\, PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.CPL, DriverData=C:\Windows\System32\Drivers\DriverData, OneDriveConsumer=C:\Users\Patrick Waldschmitt\OneDrive, ProgramData=C:\ProgramData, ProgramW6432=C:\Program Files, HOMEPATH=\Users\Patrick Waldschmitt, PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 142 Stepping 12, GenuineIntel, ProgramFiles=C:\Program Files, PUBLIC=C:\Users\Public, windir=C:\Windows, _SKIP=2, LOCALAPPDATA=C:\Users\Patrick Waldschmitt\AppData\Local, IntelliJ IDEA=C:\Program Files\JetBrains\IntelliJ IDEA 2019.2\bin;, USERDOMAIN=DESKTOP-PHVQKLV, LOGONSERVER=\\DESKTOP-PHVQKLV, JAVA_HOME=C:\Development\tools\java\jdk-8.0_201, PROMPT=$P$G, OneDrive=C:\Users\Patrick Waldschmitt\OneDrive, =C:=C:\Development\workspaces\private\my-drawer-vue\platforms\android, APPDATA=C:\Users\Patrick Waldschmitt\AppData\Roaming, JAVA_EXE=C:\Development\tools\java\jdk-8.0_201/bin/java.exe, VBOX_MSI_INSTALL_PATH=C:\Program Files\Oracle\VirtualBox\, CommonProgramFiles=C:\Program Files\Common Files, Path=C:\Program Files\AdoptOpenJDK\jdk-8.0.252.09-hotspot\bin;C:\Program Files (x86)\Razer Chroma SDK\bin;C:\Program Files\Razer Chroma SDK\bin;C:\Program Files (x86)\Razer\ChromaBroadcast\bin;C:\Program Files\Razer\ChromaBroadcast\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\PuTTY\;C:\Program Files\Git\cmd;C:\Users\Patrick Waldschmitt\AppData\Local\Microsoft\WindowsApps;C:\Program Files\JetBrains\IntelliJ IDEA 2019.2\bin;C:\HashiCorp\Vagrant\bin;C:\Program Files (x86)\Symantec\VIP Access Client\;C:\Program Files (x86)\Yarn\bin\;C:\Program Files (x86)\WinSCP\;C:\Windows\system32\config\systemprofile\AppData\Local\Microsoft\WindowsApps;;C:\Program Files\EmEditor;C:\Users\Patrick Waldschmitt\AppData\Local\Microsoft\WindowsApps;C:\Program Files\JetBrains\IntelliJ IDEA 2019.2\bin;;C:\Development\tools\node\node-v12.13.0-win-x64;C:\Development\tools\process-explorer;C:\Development\scripts;C:\Users\Patrick Waldschmitt\AppData\Local\Yarn\bin;C:\Development\tools\java\jdk-8.0_201\bin;C:\Development\tools\oc;C:\Development\tools\cwRsync_5.5.0_x86_Free\bin;C:\Development\tools\maven\apache-maven-3.6.1\bin;, OS=Windows_NT, NODE_HOME=C:\Development\tools\node\node-v12.13.0-win-x64, COMPUTERNAME=DESKTOP-PHVQKLV, PROCESSOR_REVISION=8e0c, CLASSPATH=C:\Development\workspaces\private\my-drawer-vue\platforms\android\\gradle\wrapper\gradle-wrapper.jar, CommonProgramW6432=C:\Program Files\Common Files, ComSpec=C:\Windows\system32\cmd.exe, APP_BASE_NAME=gradlew, SystemRoot=C:\Windows, TEMP=C:\Users\PATRIC~1\AppData\Local\Temp, HOMEDRIVE=C:, USERPROFILE=C:\Users\Patrick Waldschmitt, TMP=C:\Users\PATRIC~1\AppData\Local\Temp, CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files, NUMBER_OF_PROCESSORS=8}
23:32:57.086 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: STARTING
23:32:57.086 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Waiting until process started: command 'C:\Development\tools\java\jdk-8.0_201\bin\java.exe'.
23:32:57.101 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: STARTED
23:32:57.101 [DEBUG] [org.gradle.process.internal.ExecHandleRunner] waiting until streams are handled...
23:32:57.101 [INFO] [org.gradle.process.internal.DefaultExecHandle] Successfully started process 'command 'C:\Development\tools\java\jdk-8.0_201\bin\java.exe''
23:33:00.456 [LIFECYCLE] [org.gradle.process.internal.health.memory.MemoryManager] 
23:33:00.456 [DEBUG] [org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 16909922304, Free: 6037602304}
23:33:00.456 [DEBUG] [org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 16909922304, Free: 6037602304}
23:33:00.456 [DEBUG] [org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 15271460864, Committed: 709885952}
23:32:59.120 [LIFECYCLE] [class org.gradle.internal.buildevents.TaskExecutionLogger] 
23:32:59.120 [LIFECYCLE] [class org.gradle.internal.buildevents.TaskExecutionLogger] > Task :app:buildMetadata
23:33:02.098 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: SUCCEEDED
23:33:02.098 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Process 'command 'C:\Development\tools\java\jdk-8.0_201\bin\java.exe'' finished with exit value 0 (state: SUCCEEDED)
23:33:02.098 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Execute exec for :app:buildMetadata'
ptrxwsmitt picture ptrxwsmitt on 10 May 2020

I just tried to run the metadata generator manually in my project:
java -D'file.encoding=windows-1252' -D'user.country=US' -D'user.language=en' -D'user.variant' -jar android-metadata-generator.jar verbose

Same again: No output was generated in the configured output directory. It seems to be an issue with the metadatagenerator.

ptrxwsmitt picture ptrxwsmitt on 11 May 2020

I found the Issue in https://github.com/NativeScript/android-runtime/blob/master/test-app/build-tools/android-metadata-generator/src/src/com/telerik/metadata/Generator.java

The FileOutputStreams are never closed. As far as I can remember this causes Java not write the file.

ptrxwsmitt picture ptrxwsmitt on 11 May 2020

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 [email protected] and it's working now. Any ideas?

neil-119 picture neil-119 on 13 May 2020
👍1

@ptrxwsmitt

Hi Patrick, first your issue appears to be a different issue than the main issue we are discussing, could you please create a new issue and move your callstack and any other related info to it. It will help keep the discussion on both issues a lot cleaner... Your issue appears to be that your tooling isn't creating the metadata which in this case during boot up causes the exact same error -- the main issue here is that apps are randomly crashing with this error; but the metadata DOES exist but something is causing the startup to fails somehow randomly...

I found the Issue in https://github.com/NativeScript/android-runtime/blob/master/test-app/build-tools/android-metadata-generator/src/src/com/telerik/metadata/Generator.java

The FileOutputStreams are never closed. As far as I can remember this causes Java not write the file.

The files are closed in the Write function it calls. But good idea checking the source. ;-)

@neil-119 -
Can you post your callstack... And package.json for the working vs non-working version of your app? Your issue sounds like Patrick's; @ptrxwsmitt so having an idea what causes his issue would be awesome so we can get both of you fixed..

NathanaelA picture NathanaelA on 13 May 2020

@vtrifonov have you checked that issue?

vmutafov picture vmutafov on 19 May 2020

Any news or ideas how to fix/get around this issue?

Peterf89 picture Peterf89 on 30 May 2020

Just so you are aware, I have cleaned up the issue and hide comments (including some of mine :grinning:) that are out of scope; and moved @ptrxwsmitt Patricks issue into a new issue. :

As for status of this;

  1. 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.
  1. 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?

NathanaelA picture NathanaelA on 30 May 2020
👍1

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:

Galaxy A40 (a40) | 11 | 28,9%
-- | -- | --
Pixel 2 (walleye) | 7 | 18,4%
Galaxy S10e (beyond0) | 5 | 13,2%
OnePlus 7 Pro (OnePlus7Pro) | 5 | 13,2%
OnePlus 6 (OnePlus6) | 3 | 7,9%
Galaxy S10 (beyond1) | 3 | 7,9%
Galaxy A30 (a30) | 2 | 5,3%
Galaxy Note10+ (d2s) | 1 | 2,6%
OnePlus6T (OnePlus6T)

Peterf89 picture Peterf89 on 30 May 2020
👍1

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?

7ammer picture 7ammer on 9 Jun 2020

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 ReferenceError: __metadata is not defined.

Google Pixel 2 (walleye), 3840MB RAM, Android 10
Report 1 of 2

java.lang.RuntimeException: Unable to create application com.tns.NativeScriptApplication: com.tns.NativeScriptException: Error calling module function 
ReferenceError: __metadata is not defined
File: (file:///data/data/com.prayer247.lectio365/files/app/vendor.js:1:1364427)
(file
at (file:///data/data/com.prayer247.lectio365/files/app/vendor.js:1:1364546)
at __webpack_require__(file:///data/data/com.prayer247.lectio365/files/app/runtime.js:1:686)
at (file:///data/data/com.prayer247.lectio365/files/app/vendor.js:1:1347819)
at __webpack_require__(file:///data/data/com.prayer247.lectio365/files/app/runtime.js:1:686)
at (file:///data/data/com.prayer247.lectio365/files/app/bundle.js:1:44455)
at __webpack_require__(file:///data/data/com.prayer247.lectio365/files/app/runtime.js:1:686)
at (file:///data/data/com.prayer247.lectio365/files/app/bundle.js:1:44255)
at __webpack_require__(file:///data/data/com.prayer247.lectio365/files/app/runtime.js:1:686)
at (file:///data/data/com.prayer247.lectio365/files/app/bundle.js:1:236319)
at __webpack_require__(file:///data/data/com.prayer247.lectio365/files/app/runtime.js:1:686)
at (file:///data/data/com.prayer247.lectio365/files/app/bundle.js:1:69604)
at __webpack_require__(file:///data/data/com.prayer247.lectio365/files/app/runtime.js:1:686)
at (file:///data/data/com.prayer247.lectio365/files/app/bundle.js:1:16648)
at __webpack_require__(file:///data/data/com.prayer247.lectio365/files/app/runtime.js:1:686)
at (file:///data/data/com.prayer247.lectio365/files/app/bundle.js:1:93079)
at (file:///data/data/com.prayer247.lectio365/files/app/bundle.js:1:94617)
at __webpack_require__(file:///data/data/com.prayer247.lectio365/files/app/runtime.js:1:686)
at checkDeferredModules(file:///data/data/com.prayer247.lectio365/files/app/runtime.js:1:508)
at webpackJsonpCallback(file:///data/data/com.prayer247.lectio365/files/app/runtime.js:1:331)
at (file:///data/data/com.prayer247.lectio365/files/app/bundle.js:1:169)
  at .require (1:266)
  at .ReferenceError
  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)
  at .__webpack_require__
  at .__webpack_require__
  at .__webpack_require__
  at .__webpack_require__
  at .__webpack_require__
  at .__webpack_require__
  at .__webpack_require__
  at .__webpack_require__
  at .checkDeferredModules
  at .webpackJsonpCallback
  at .require (1:266)
  at .ReferenceError
  at com.tns.Runtime.runModule (Native Method)
  at com.tns.Runtime.runModule (Runtime.java:674)
  at com.tns.Runtime.run (Runtime.java:666)
  at com.tns.NativeScriptApplication.onCreate (NativeScriptApplication.java:21)
  at android.app.Instrumentation.callApplicationOnCreate (Instrumentation.java:1189)
  at android.app.ActivityThread.handleBindApplication (ActivityThread.java:6460)
7ammer picture 7ammer on 9 Jun 2020

I got rid of the crashes btw by downgrading NS Android runtime to [email protected] as suggested by Neill and then in return I got a lot of ANRs :(

Peterf89 picture Peterf89 on 9 Jun 2020

@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. :)

NathanaelA picture NathanaelA on 9 Jun 2020
🎉2 ❤1

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 https://github.com/NativeScript/android-runtime/issues/1546#issuecomment-623071675 that she duplicated it using the latest updates on a Pixel 4.

Can anyone tell me if:

  1. Phone is hooked to a google account
  2. Backups are turned on
  3. Lock screen (no lock screen, type of lockscreen) [ Pattern, No notifications shown ]
  4. ADB version
  5. OS (Linux, Mac, Windows) running. [Linux]
  6. Connected to Wifi/Bluetooth [Wifi]
    7.Is the device plugins in via adb the entire time during reboot? [Yes]
  7. Any specific developer settings turned on besides adb debugging

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 --buffer=crash is working.

NathanaelA picture NathanaelA on 12 Jun 2020

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!!!

NathanaelA picture NathanaelA on 12 Jun 2020
🎉2 ❤1

awesome looking forward for the PR of the fix :)

saschaarthur picture saschaarthur on 12 Jun 2020

@NathanaelA Have you already found out what is causing the crashes in combination with the lock screen?

jessorlisa picture jessorlisa on 19 Jun 2020

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. :-)

NathanaelA picture NathanaelA on 19 Jun 2020

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:

  • The Local Notification plugin has a bootup receiver notification, but not just ANY phone bootup receiver notification, but the newer Android 7 bootup receiver notification even if phone is still locked ultra secure version 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? :grinning: In DIRECT_BOOT the 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 a DIRECT_BOOT receiver 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.

  • When this receiver is triggered the receiver code loads and does what it is supposed to; however it is also triggering the native side of the NativeScript app to also boot. So when that part attempts to boot, it fails. It has no access to its files and the metadata is the first set of files it attempts to load. However, in all reality this part of the code does NOT need to actually run when the receiver is triggered at bootup. Unfortunately, The OS doesn't know any better, so it just triggers it (or at least that appears to be what is triggering it) when it fired the receiver.

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 picture NathanaelA on 21 Jun 2020
🎉5 ❤2 👍2 🚀1

@NathanaelA you are legendary <3

shiv19 picture shiv19 on 21 Jun 2020

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 :)

saschaarthur picture saschaarthur on 21 Jun 2020

@NathanaelA! That is some Sherlock level deduction there! :) Well done and thank you for all your effort!

7ammer picture 7ammer on 22 Jun 2020

@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 picture jessorlisa on 25 Jun 2020

@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.

NathanaelA picture NathanaelA on 25 Jun 2020
👍2 🚀1

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. :grinning:

NathanaelA picture NathanaelA on 8 Jul 2020

Just updated to 6.5.2, sadly tns run android fails with:

Error executing Metadata Generator: java.nio.IntBuffer.clear()Ljava/nio/IntBuffer;
Detailed log here: ../testcrash/platforms/android/build-tools/buildMetadata.log

Unable to apply changes on device: 9A231FFAZ00184. Error is: Command ./gradlew failed with exit code 1.

../testcrash/platforms/android/build-tools/buildMetadata.log:

java.lang.NoSuchMethodError: java.nio.IntBuffer.clear()Ljava/nio/IntBuffer;
    at com.telerik.metadata.Writer.writeTree(Writer.java:349)
    at com.telerik.metadata.Generator.main(Generator.java:60)

Steps to reproduce:

tns create testcrash --js
cd testcrash
tns platform add android // now 6.5.0 is added
tns platform remove android
tns platform add android // latest version 6.5.2 is added
tns run android

Is there anything else that needs to be updated?

tns info   
✔ Getting NativeScript components versions information...
⚠ Update available for component nativescript. Your current version is 6.7.4 and the latest available version is 6.7.8.
✔ Component tns-core-modules has 6.5.8 version and is up to date.
✔ Component tns-android has 6.5.2 version and is up to date.
jessorlisa picture jessorlisa on 8 Jul 2020
😕3

@NathanaelA

Can fully confirm, that all our pipelines turned red after updating to the latest ns runtime..
Everyone updating Nativescript currently, resulting in a broken runtime version..

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 (https://github.com/NativeScript/android-runtime/issues/1623).
Im willing to support here if needed, just let me know where to start..

Anyways the reason for this seems to be: https://jira.mongodb.org/browse/JAVA-2559
(prob a lib/java) was updated to use java-9?!

saschaarthur picture saschaarthur on 8 Jul 2020

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.

NathanaelA picture NathanaelA on 8 Jul 2020

@saschaarthur @jessorlisa - I have released a v6.5.3 that fixes the metadata building issue on Java 8. Sorry about the issues!

NathanaelA picture NathanaelA on 8 Jul 2020

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.

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?

saschaarthur picture saschaarthur on 8 Jul 2020

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... :grinning:

NathanaelA picture NathanaelA on 9 Jul 2020

@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.

jessorlisa picture jessorlisa on 18 Jul 2020
👍3
Was this page helpful?
0 / 5 - 0 ratings

Related issues

georgeedwards picture georgeedwards  ·  3Comments
m-abs picture m-abs  ·  3Comments
NathanaelA picture NathanaelA  ·  3Comments
romulowspp picture romulowspp  ·  4Comments
EddyVerbruggen picture EddyVerbruggen  ·  5Comments