GeezerVison

PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for.
• You have signed the CLA.
• All existing tests are passing.
• Tests for the changes are included.

What is the current behavior?

A FragmentClass can outlive the BackstackEntry it is bound to, and the FragmentManager then drives it through the lifecycle against that dead entry. The reported symptom is a fatal:

com.tns.NativeScriptException: Calling js method onCreateView failed
Error: fragment0[0]<null>.onCreateView: entry has no resolvedPage
	at com.tns.FragmentClass.onCreateView(FragmentClass.java:55)
	at androidx.fragment.app.Fragment.performCreateView(Fragment.java:3119)
	at androidx.fragment.app.FragmentStateManager.createView(FragmentStateManager.java:577)
	at androidx.fragment.app.FragmentStateManager.moveToExpectedState(FragmentStateManager.java:286)
	at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:2211)
	at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:2106)
	at androidx.fragment.app.FragmentManager.execPendingActions(FragmentManager.java:2049)

Note <null> in the fragment's toString: the fragment's entry is intact, only resolvedPage is gone.

How the fragment gets stranded. Navigation only evicts fragments via transaction.replace(this.containerViewId, ...), which removes added fragments in that container. Frame._removeEntry then clears resolvedPage (FrameBase._removeEntry) and drops entry.fragment, but never tells the FragmentManager anything — it assumes the replace already did. That assumption breaks for any fragment whose container is no longer the frame's current container: leftovers from an activity recreation, a frame/root-view reset, or a navigation that was interrupted mid-flight. Such a fragment stays mAdded, so moveToExpectedState() keeps promoting it, and it gets onCreateView again after its entry has been discarded.

Why it is fatal rather than a no-op. Every callback on that path either reported the condition through Trace.error — which routes to DefaultErrorHandler, rethrows, and surfaces as an uncaught exception across the JNI boundary — or dereferenced the missing page directly:

• onCreateView — fixed in fix(android): don't crash in Fragment.onCreateView on stale-fragment race #11264, but that only moved the crash one step later, since the fragment continues to…
• onResume — this.entry.resolvedPage.frame throws a TypeError on the very same stale fragment
• onDestroy — Trace.error on a missing entry, which is exactly what a discarded fragment hits on teardown
• onPause / onDestroyView — this.frame.nativeViewProtected with no frame
• findPageForFragment — throw new Error('Could not find a page for <tag>') for a restored fragment no live entry claims

This correlates strongly with memory pressure: the tighter memory gets, the more the OS destroys and recreates activities, which is what strands the fragments in the first place. It was reported from production with 300+ occurrences on low-RAM (4 GB) devices, mostly on resume after the app had been idle.

What is the new behavior?

The stale fragment is discarded instead of taking the app down, and it stops being stale in the first place:

• Frame._removeEntry — when the discarded entry still has a fragment, detach the fragment's callbacks (entry/frame) and remove it from its FragmentManager if it is still added. This is the actual leak fix: the guard only fires for fragments that are still added while their entry is being discarded, i.e. exactly the orphans. In normal forward/back/clearHistory/backstackVisible: false navigation the outgoing fragment has already been evicted by the replace before setCurrent runs, so isAdded() is false and nothing changes.
• findPageForFragment — widen the entry lookup through the (previously unused) _findEntryForTag, which also searches the backstack and the navigation queue, so fragments Android restored from those are matched rather than declared orphans. When there genuinely is no entry, log and remove the fragment instead of throwing.
• onDestroy / onResume / onPause / onDestroyView — treat a missing entry, page or frame as the recoverable state it is. onResume in particular had to be guarded, or the onCreateView fix from fix(android): don't crash in Fragment.onCreateView on stale-fragment race #11264 just relocates the crash.

Removals are always committed with commitAllowingStateLoss(): callers can be inside a FragmentManager transaction (findPageForFragment runs from onCreate, _removeEntry from a transition listener), where commitNow throws "FragmentManager is already executing transactions".

Also considered and left out: extending the restored-fragment cleanup in ActivityCallbacksImplementation.onCreate (which deliberately skips fragment* tags) to drop unclaimed NativeScript fragments. Having each orphan remove itself in its own onCreate is ordering-independent and also covers child FragmentManagers, which that cleanup does not walk.

No unit tests: packages/core specs cover parser/pure-logic modules only and nothing platform-specific, and these are FragmentManager lifecycle paths. Verification is on device — activity destroy/recreate (Don't keep activities) with a navigation in flight, plus tabs/bottom-navigation nested frames on resume.