Application with nested frame crash with suspend/resume during transition of parent frame.
This crash might be reproduced with various app suspend/resume scenarios.
Isolated scenarios using this playground app with slow transitions between pages:
Steps:
Steps:
Steps:
We are having the same issue!
@Firetrip does your scenario match the steps to reproduce above? If not -- can you elaborate on your scenario as it might be a different issue that leads to the same error (but might require a different fix)?
I just had a report of the same issue. My scenario clearly involve suspend but i don't have the exact scenario right now
@manoldonev
my scenario is really simple.
Step 1:
Navigation from Master to Detail
Step 2:
Navigation from Detail to Master with Android Back Button
While navigation happens, suspend app, or just tab to android task manager
App crashes with
"Error: java.lang.IllegalArgumentException: No view found for id 0x6 (unkown) for fragement FragmentBase_vendor_97153_32_TabFragmentImplementation..."
@Firetrip can you let us know on what device and OS you are having the issue No view found for id 0x6
I have an even simpler scenario which will crash regardless of what screen is displayed.
Crash log:
An uncaught Exception occurred on "main" thread.
Unable to resume activity {com.tns.nativescript.app/com.tns.NativeScriptActivity}: java.lang.IllegalArgumentException: No view found for id 0x3 (unknown) for fragment fragment2[2]<t(27)>
StackTrace:
java.lang.RuntimeException: Unable to resume activity {com.tns.nativescript.app/com.tns.NativeScriptActivity}: java.lang.IllegalArgumentException: No view found for id 0x3 (unknown) for fragment fragment2[2]<t(27)>
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:4322)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:4354)
at android.app.servertransaction.ResumeActivityItem.execute(ResumeActivityItem.java:52)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:176)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2109)
at android.os.Handler.dispatchMessage(Handler.java:107)
at android.os.Looper.loop(Looper.java:214)
at android.app.ActivityThread.main(ActivityThread.java:7682)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:516)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:950)
Caused by: java.lang.IllegalArgumentException: No view found for id 0x3 (unknown) for fragment fragment2[2]<t(27)>
at androidx.fragment.app.FragmentManagerImpl.moveToState(FragmentManager.java:1454)
at androidx.fragment.app.FragmentManagerImpl.moveFragmentToExpectedState(FragmentManager.java:1784)
at androidx.fragment.app.FragmentManagerImpl.moveToState(FragmentManager.java:1852)
at androidx.fragment.app.BackStackRecord.executeOps(BackStackRecord.java:802)
at androidx.fragment.app.FragmentManagerImpl.executeOps(FragmentManager.java:2625)
at androidx.fragment.app.FragmentManagerImpl.executeOpsTogether(FragmentManager.java:2411)
at androidx.fragment.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(FragmentManager.java:2366)
at androidx.fragment.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:2273)
at androidx.fragment.app.FragmentController.execPendingActions(FragmentController.java:391)
at androidx.fragment.app.FragmentActivity.onResume(FragmentActivity.java:517)
at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1560)
at android.app.Activity.performResume(Activity.java:7952)
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:4312)
... 11 more
Device details:
Appears to have been caused by the update to OxygenOS 10.0.2 - the same app was running fine prior to this update, and is still broken on 10.0.3.
@NickIliev sorry i totally missed your question. It is happening on a Xiaomi Mi 9 EU Version with Android 10 installed.
I just noticed that it happens in different scenarios. Not sure if it is related to the changes i implemented, but now i also can notice it with the scenario @dnjohnson described.
Some more information.
After reverting the last changes i am unable to reproduce the issue when just switching from app to home again and again.
I had an call to firebase.areNotificationsEnabled() on my mains page ngOnInit().
in addition i accessed the secure local storage in the app.resumeEvent. One of those calls may to cause the issue. most likely the access to the storage in the app resume event.
Nevermind my previous comment.
We testet it with various devices. All Android 10 devices suffer from the crash. We really need a fix for this :/
I did some logging and debugging.
the exception is caused by this._currentTransaction.commitNowAllowingStateLoss();
usually _currentTransaction is based on a fragment manager detected in view.android.js in the function _getFragmentManager()
I am not certain, but it seems to work as long as this function returns a fragment manager with view._getChildFragmentManager(
, resulting in a fragmentManager looking kinda like this:
FragmentManager{1316099 in FragmentClass{cf2e3e4}}
When we start committing the transaction the getter method for _currentTransaction is called another two times, basing the transaction all two times (once in the if clause, once when actually calling this._currentTransaction.commitNowAllowingStateLoss();
) on a FragmentManager from a frameOrTabView (by calling the above mentioned view._getChildFragmentManager()).
Even before the committing the found fragment manager in the instantiateItem method is one found by view_getChildFragmentManager().
In the case of the crash however something before that goes wrong. The changeTab method is called, which in turn calls instantiateItem, which needs a fragement manager.
Here are the steps that happen in the view.android.js _getFragmentManager method.
it goes into the inner if clause of view._hasFragment, view._getChildFragmentManager() immediately. This however returns null
. There is no other fragementManager found before that.
After that it of course detects that the manager property is null and uses the rootManager, which kinda looks like this when logged: FragmentManager{35ca183 in HostCallbacks{b158d7e}}
This means that we now (most likely) work with the wrong FragmentManager, as it is the root manager instead of a child manager.
As soon as we try to call commitNowAllowingStateLoss() the app crashes.
Maybe that helps :)
@Firetrip just to push your point I really think the _getFragmentManager method is wrong in the manner that it does not always return the same manager. We had that case in another issue with closing and disposing a fragment. It was fixed without fixing the _getFragmentManager method
Same for me
Possible solution: https://stackoverflow.com/a/8158916
Just confirming still happening in Android 10.3.1
Some workaround? or some tips?
I'm stucked here and i have no more idea.
I have the same when using nested Frame (NativeScript-Vue) but seems only to happen on Android 10. I tested on my Xiaomi MIUI11 and One plus Oxygen OS 10.0.1 both running on Android 10. On a Samsung phone running Android 6 no problem.
so,
i want try building with sdk 28.
I let you know.
no,
same crash error building with sdk 28.
i found this workaround, but it's so ugly.
_app.on(_app.suspendEvent, function(args) {
if (args.android) {
var app_frame= _frame.getFrameById("app_frame");
if(app_frame){
app_frame.navigate({ moduleName: "toor/toor-page"});
}
});
on suspend, i throw a navigation.
when the app is resumed, it returns to the first page but
it does not crash.
After doing some playing around, I've discovered this is only happening to our app when we have a nested page-router-outlet
.
When we change the inner route to router-outlet
as per recommendations in the documentation then the crash no longer occurs. Of course, when we do that we lose some of the advantages of using page-router-outlet
but it's easier to workaround them then the app crashing.
I'm unsure if this is what's causing the crash for others as well or if there are multiple scenarios.
I'm currently using the core implementation not the angular one.
What are the difference between page-router-outlet
androuter-outlet
?
The page-router-outlet
creates a mobile navigation (for example on iOS there is a UINavigaitonBar
) where we have an ActionBar by default. The PRO (page-router-outlet
) also will be able to navigate back through the mobile back button (e.g. the hardware back button for Android and the Navigation's back button on iOS)
Normally, you would want to have a PRO only for your top navigation and the nested routers should use a router-outlet
(where there is no Actionbar and no hardware back button option ad you will have to use entirely the Angular routing techniques)
do you have some idea about how to fix/workaround this bug in nativescript/core ?
my bad workaround does not cover all cases and bring always back to homepage.
So I'm not sure what happened there.
I made a playground with NativeScript-Vue to reproduce my problem: https://play.nativescript.org/?template=play-vue&id=1sx3qd&v=9
After I tested the playground I figured out that I didn't have the problem anymore on my Xiaomi MIUI 11.2, Android 10, SDK 29. I checked the runtime version on Playground and it was the latest 6.5.0
(released yesterday) or in my App I use the 6.4.1
.
So I upgraded both tns-core-module
and tns-android
to 6.5.0
in my App and I didn't have the problem anymore.
I tested on my One Plus phone running H虏OS 10.0.1, Android 10, SDK29, I still have the issue. Not sure why on that phone brand I have this problem, also I didn't update my Xiaomi phone since last time.
I made a workaround which can be found in the playground above in app.js
line 31,32. Like @deivdev did, every time I navigate with navigateTo
method I will store the current navigation and in the suspendEvent
, I will navigate to the last navigation to avoid the crash.
However, using this workaround in my App, it will cause each time before I call navigateTo
a white screen before navigating to the page. So right now I only use this workaround on the One Plus phone.
I am having the same issue. Mine is a simpler scenario just like the one @dnjohnson described.
It seems to be an intermittent issue.
I noticed here some discussion about using PRO, so I do have it set on my landing page.
Here we go with the code.
I am not sure if it's related but I was having an issue where two ActionBars were being displayed when navigating through views, then I fixed it by doing this.page.actionBarHidden = true;
in the inner page. As a result of that, only the below ActionBar is displayed even when navigating through other pages. Could not figured out why two ActionBars were displayed.
<ActionBar>
<ActionItem visibility="{{ actionBarItemVisibility }}">
<StackLayout ripple rippleColor="#c2c2c2" style="border-radius: 50;" (tap)="onDrawerButtonTap($event)">
<Label text="" class="fas menu-icon"></Label>
</StackLayout>
</ActionItem>
</ActionBar>
<RadSideDrawer #rsd drawerTransition="PushTransition">
<GridLayout tkDrawerContent rows="auto, *" class="sidedrawer sidedrawer-left">
<!-- ommited code here -->
</GridLayout>
<page-router-outlet tkMainContent class="page page-content">
</page-router-outlet>
</RadSideDrawer>
This bug is becoming frustrating. Some workaround?
The nativescript team working on it? Thank you
On crashlytics I've many entries with this issue. Did you know how to solve it?
Fatal Exception: java.lang.RuntimeException: Unable to resume activity {it.copergmps.rt.pf.android.sp.bmps/com.tns.NativeScriptActivity}: java.lang.IllegalArgumentException: No view found for id 0x38 (unknown) for fragment fragment40[36]<t(4039)>
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:4026)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:4058)
at android.app.servertransaction.ResumeActivityItem.execute(ResumeActivityItem.java:51)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:145)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:70)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1960)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:214)
at android.app.ActivityThread.main(ActivityThread.java:7094)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:494)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:975)
Do I need to open another issue on GitHub?
Does this frustrating Nativescript bug have any team members able to fix it?
A reply would be much appreciated!
I鈥檓 struggling with this one too. It鈥檚 indeed very frustrating.
Do any of you guys have a very simple repro project? Not using angular would be best.
I can look at it andfix but i need a repro project
I need this feature done. Any prevision?
Sorry guys (& gals), I just saw this issue the other day, so I have assigned it to myself to work on it. I plan on working on this probably next week, however it might be the following week as paid support contract bugs always have a higher priority. If any of you have a paid support plan and this is affecting you, please feel free to drop this into that support system and it will bump the priority. Otherwise please note, we will be working on it...
Hi @NathanaelA news for this bug?
still happens on NS-Core
@deivdev - Do you have a sample simple app using NSCore; the simpler the case and/or even complicated but always fails makes debugging these issues a lot easier. :grinning:
when will it be fixed?
I need this feature done. Any prevision?
farfromrefug:
Do any of you guys have a very simple repro project? Not using angular would be best.
I can look at it andfix but i need a repro project
NathanaelA:
- Can any of you verify if it happens on a NS-Core / PAN application, or do you have to use Vue/Angular to see this issue?
- Do any of you have a sample that is a PAN/Core sample that fails?
- Does this still happen with NS 6.5
NathanaelA
Do you have a sample simple app using NSCore; the simpler the case and/or even complicated but always fails makes debugging these issues a lot easier. 馃榾
We are still missing key information @a92c - if this is blocking you, then please do share a sample we can work with...
no news related with this problem?
@ruanorz no news - the questions from https://github.com/NativeScript/NativeScript/issues/8126#issuecomment-691951330 are still awaiting responses!
Hi guys, I've upgraded my project dependencies, and the problem disappeared.
Here is part of my package.json, did you tried to upgrade to ns/core 6.5.0?
"nativescript": {
"tns-android": {
"version": "6.5.0-2020-04-13-120923-01"
},
"tns-ios": {
"version": "6.5.3"
}
},
"dependencies": {
"@nativescript/core": "6.5.0",
"@nativescript/theme": "^2.3.3",
"@panter/vue-i18next": "^0.15.2",
"@vue/devtools": "^5.3.3",
"axios": "^0.19.2",
"i18next": "^19.4.5",
"lodash": "^4.17.15",
"moment": "^2.24.0",
"nativescript-appversion": "^1.4.4",
"nativescript-clipboard": "^2.0.0",
"nativescript-datetimepicker": "^1.2.2",
"nativescript-geolocation": "^5.1.0",
"nativescript-image-cache-it": "^5.0.0-beta.20",
"nativescript-inappbrowser": "^2.3.0",
"nativescript-mapbox": "4.3.1",
"nativescript-material-ripple": "^3.2.3",
"nativescript-plugin-firebase": "^10.5.2",
"nativescript-socketio": "^3.3.1",
"nativescript-soft-keyboard": "^1.0.0",
"nativescript-svg": "^1.3.7",
"nativescript-toasty": "^3.0.0-alpha.2",
"nativescript-ui-sidedrawer": "^8.0.1",
"nativescript-urlhandler": "^1.3.0",
"nativescript-vue": "^2.7.1",
"nativescript-vue-shadow": "^0.1.0",
"rxjs": "^6.5.5",
"vuex": "^3.1.2"
},
Most helpful comment
Sorry guys (& gals), I just saw this issue the other day, so I have assigned it to myself to work on it. I plan on working on this probably next week, however it might be the following week as paid support contract bugs always have a higher priority. If any of you have a paid support plan and this is affecting you, please feel free to drop this into that support system and it will bump the priority. Otherwise please note, we will be working on it...