[New Arch] react-native-screens Fragment accumulation bloats onSaveInstanceState → TransactionTooLargeException on activityStopped

[MisterMunchkin]

Description

Under the New Architecture (Fabric), react-native-screens mounts one native Fragment per pushed screen (ScreenStackFragment, each with a nested childFragmentManager/ScreenFragment). On a deep push-navigation stack these accumulate in the host Activity's saved state. When the OS stops the Activity (app backgrounded), onSaveInstanceState serialises all of them, and in a real app the parcel exceeds the Binder transaction budget → fatal, unhandled android.os.TransactionTooLargeException on activityStopped.

This is a save-time crash, distinct from the well-known restore-time crashes (#17, #3317) that AutoRemovingFragment / RNScreensFragmentFactory / super.onCreate(null) address. Those do not help here: the oversized parcel is rejected by the Binder at save time, before any restore.

Production crash evidence. Real TooLargeTool-style breakdown from a shipping app on this stack (the parcel that crashed at activityStopped, ~639 KB):

androidx.lifecycle.BundlableSavedStateRegistry.key [637 KB]
    android:support:activity-result [208 KB]
    android:support:fragments      [428 KB]   <- ~150 ScreenStackFragment/ScreenFragment entries
        fragment_<uuid> [2868]
            childFragmentManager [2176]
                fragment_<uuid> [1752]
                    childFragmentManager [1068]
        ... (x150)

• Device: Samsung Galaxy A57 (SM-A576B), Android 16, 7.8 GB RAM — not low-memory.
• Each real fragment contributes ~2.8 KB (FragmentManager metadata + the nested childFragmentManager); at 150+ retained fragments this is 428 KB.

About the reproduction (please read). The linked repo demonstrates the accumulation mechanism — it auto-pushes a native-stack screen and logs, on background, the saved-state parcel size and that android:support:fragments is present (regHasFragments=true). It does not, by itself, cross the ~1 MB limit and crash, and that is worth stating plainly: with trivial screens the saved state is only ~75 bytes/fragment (measured on API 34), so a toy stack stays far under the limit. The production crash is emergent from real screens × deep navigation (real screens save ~2.8 KB/fragment; long sessions reach 150+ retained fragments). The repo shows the code path and lets you watch the parcel grow with depth; the crash-scale evidence is the production bundle above.

Why this seems in scope for react-native-screens. RNS already declares its fragments non-restorable — it discards restored fragment state and rebuilds from JS (AutoRemovingFragment, and the discussion in #96). But it still lets that state be saved into the Activity parcel, where on deep stacks it triggers TransactionTooLargeException. Since RNS never consumes the saved fragment state, arguably it should not let it balloon the save parcel — e.g. opt its ScreenStackFragments out of instance-state saving, or expose a supported way to bound it.

App-side workaround (and a gotcha). Stripping the fragment state in MainActivity.onSaveInstanceState stops the crash — RNS rebuilds fine from JS. Note: on androidx.fragment 1.8.x the FragmentManager state is saved via SavedStateRegistry, so it is nested — the classic top-level outState.remove("android:support:fragments") is a no-op (measured: 0 bytes removed). It must be reached inside the registry bundle:

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.getBundle("androidx.lifecycle.BundlableSavedStateRegistry.key")
        ?.remove("android:support:fragments")
}

This depends on internal androidx key strings, which is why a first-party RNS option would be preferable.

Steps to reproduce

Reproduction repo: https://github.com/MisterMunchkin/rns-4487-repro

1. git clone https://github.com/MisterMunchkin/rns-4487-repro && cd rns-4487-repro && npm install
2. npx expo prebuild --platform android --clean then npx expo run:android on an Android 13+ emulator/device. New Architecture is enabled via app.json; a parcel-size logger is injected into MainActivity by plugins/with-parcel-logger.js.
3. In a second terminal: adb logcat -s RNSRepro.
4. The app auto-pushes a self-referential native-stack screen to TARGET_DEPTH. When it settles, enable Developer Options → "Don't keep activities" (forces the save+stop deterministically on an emulator; production hits it via natural memory pressure), then press Home.
5. RNSRepro logs onSaveInstanceState parcel=<N> bytes | regHasFragments=true — confirming the react-native-screens fragments accumulate in the Activity's saved state (nested under androidx.lifecycle.BundlableSavedStateRegistry.key). Raise TARGET_DEPTH (or run against content-heavy screens) to watch the parcel climb toward the Binder limit; at production scale (real screens, 150+ fragments ≈ 428 KB) it crosses ~639 KB and throws TransactionTooLargeException at activityStopped.

Snack or a link to a repository

https://github.com/MisterMunchkin/rns-4487-repro

Screens version

4.18.0

React Native version

0.81.5

Platforms

Android

JavaScript runtime

Hermes

Workflow

Expo bare workflow (expo prebuild / CNG; androidx.fragment 1.8.9)

Device

Real device (production crash) + Android emulator (mechanism)

Device model

Samsung Galaxy A57 (SM-A576B), Android 16

Acknowledgements

Yes

[t0maboro]

Hi @MisterMunchkin , thanks for the report. I've investigated this, but a standard push stack does not accumulate fragments in the Activity's saved state on my side. Testing on the example that you provided, the saved parcel doesn't scale with depth. At TARGET_DEPTH=3 and TARGET_DEPTH=100 in your example I am observing exactly the same log.

2026-08-12 10:57:00.842  4150-4150  RNSRepro                com.example.rns4487repro             E  onSaveInstanceState parcel=3952 bytes | regHasFragments=true

What would mean that inactive fragments are detached properly. Can you share a reproduction where the parcel size clearly scales up with push depth? Or a screen recording for this repro if it scales with stack depth on your end?

[MisterMunchkin]

Hi @t0maboro, sorry for the late update on this, and thanks for taking the time to test this!

You're right, and it led me to the actual mechanism. Short version: a plain push stack genuinely does not scale — but the parcel scales linearly the moment screens are retained rather than removed, which is what happens with translucent presentations (transparentModal / formSheet) and nested navigators. My original repro used opaque pushes, which is exactly the case RNS optimises away, so it could never show the growth. Here is the corrected picture, measured on Android 16 (RNS 4.18.0, RN 0.81.5, New Arch/Fabric).

1. You're correct about the opaque push stack

Reproduced your result exactly — a plain navigation.push stack is flat:

push depth	onSaveInstanceState parcel
3	3952 bytes
100	3952 bytes

Because in ScreenStack.kt, for an opaque top screen visibleBottom == null, so the stack update transaction.remove()s every fragment except the top one. A removed fragment isn't serialised into onSaveInstanceState, so the parcel is constant regardless of depth — the N screens live in react-navigation's JS state, not as N saved Android fragments. My first repro was mis-designed; apologies for the noise.

(depth 100/100, parcel still 3952 B)

2. The parcel does scale — as soon as fragments stay add()-ed

Fragments only accumulate in the saved state when they remain added. RNS keeps them added for translucent presentations — Screen.isTranslucent() returns true for TRANSPARENT_MODAL and FORM_SHEET — and for nested navigators.

Same repo, same device, only the presentation changed. An opaque root with a stack of transparentModal screens on top:

push depth	opaque push	transparentModal
3	3952	8152
20	3952	31952
40	3952	59952

That is an exact linear fit parcel = 3952 + 1400 * depth (R² = 1) — ≈1.4 KB per retained fragment with trivial screens. This is the "reproduction where the parcel clearly scales with push depth" you asked for.

(depth 40 — ~12 retained transparent layers stacked at once; each visible card is a ScreenStackFragment still add()-ed)

3. The real production trigger: nested navigators + a translucent sheet

The app where we hit the production TransactionTooLargeException on activityStopped doesn't use transparentModal at all. It's a deeply nested react-navigation tree — roughly:

Root native-Stack
└─ Bottom-Tabs (no detachInactiveScreens / freezeOnBlur — v7 defaults)
     ├─ Tab → native-Stack
     ├─ Tab → native-Stack
     └─ Tab → native-Stack → (further) native-Stack   ← double nesting
   + one  presentation: 'formSheet'  group presented on top of the root stack

That recursive fragment → childFragmentManager → fragment → childFragmentManager … structure in the crashed parcel is this nested navigator tree. Bottom-tabs keeps every visited tab's stack mounted, and the translucent formSheet on top keeps the whole tree beneath it add()-ed at save time.

Minimal faithful repro of that shape (3 tabs, one double-nested, trivial screens), Android 16:

configuration	parcel
opaque baseline	3952 bytes
nested tabs, no sheet	7176 bytes
nested tabs + formSheet	8576 bytes

Modest here only because it's a toy tree with trivial screens — the accumulation is by breadth (mounted navigator nodes × nesting), not depth. In the production app the tree is several tabs wide × multiple nesting levels, real screens save ≈2.8 KB per fragment, and a long session retains ≈150 fragments ≈ 428 KB of android:support:fragments (≈639 KB total parcel) — over the Binder limit → fatal TransactionTooLargeException on activityStopped. Device: a mid-range phone on Android 16, 7.8 GB RAM (not low-memory).

(formSheet presented over the nested tab tree)

4. Why this seems in scope for react-native-screens

RNS already declares its fragments non-restorable — it discards restored fragment state and rebuilds from JS (AutoRemovingFragment, super.onCreate(null), and the discussion in #96). But it still lets that state be saved into the Activity parcel, where on a retained-fragment-heavy tree it triggers TransactionTooLargeException. Since RNS never consumes the saved fragment state, it arguably shouldn't let it balloon the save parcel.

The only app-side workaround we found depends on internal androidx key strings — on androidx.fragment 1.8.x the FragmentManager state is nested inside SavedStateRegistry, so the classic top-level outState.remove("android:support:fragments") is a no-op; it has to be reached inside the registry bundle:

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.getBundle("androidx.lifecycle.BundlableSavedStateRegistry.key")
        ?.remove("android:support:fragments")
}

This works and is what we currently ship, but it depends on internal androidx keys. A first-party option — opting RNS's own ScreenStackFragments out of instance-state saving, or a supported way to bound it — would be much preferable.

Repro & environment

• Corrected repro: https://github.com/MisterMunchkin/rns-4487-repro — set MODE in App.tsx (opaque / transparentModal / nested) and background the app; it logs the onSaveInstanceState parcel size.
• RNS 4.18.0, RN 0.81.5, Expo SDK 54, @react-navigation/native-stack v7 + @react-navigation/bottom-tabs v7, New Architecture (Fabric) ON, Android 16 (emulator + real device).
• Method: inject an onSaveInstanceState logger into MainActivity, enable Developer Options → "Don't keep activities", press Home; read the parcel size from logcat.

AI GENERATED

[t0maboro]

Confirming that's reproducible, adding to our queue

MRE

import * as React from 'react';
import { Button, StyleSheet, Text, View } from 'react-native';
import { NavigationContainer } from '@react-navigation/native';
import {
  createNativeStackNavigator,
  NativeStackScreenProps,
} from '@react-navigation/native-stack';

const MODAL_COUNT = 140;
const AUTO_PUSH_INTERVAL_MS = 120;

type RootParamList = {
  Home: undefined;
  Modal: { depth: number };
};

type InnerParamList = {
  InnerHome: { label: string };
};

const Root = createNativeStackNavigator<RootParamList>();
const Inner = createNativeStackNavigator<InnerParamList>();

function HomeScreen({
  navigation,
}: NativeStackScreenProps<RootParamList, 'Home'>) {
  return (
    <View style={styles.home}>
      <Text style={styles.title}>#4487 saved-state parcel growth</Text>
      <Text style={styles.hint}>
        Press Home for a baseline, push the modals, press Home again and compare
        `adb logcat -s RNS4487`.
      </Text>
      <Button
        title={`Push ${MODAL_COUNT} transparent modals`}
        onPress={() => navigation.push('Modal', { depth: 1 })}
      />
    </View>
  );
}

function InnerHomeScreen({
  route,
}: NativeStackScreenProps<InnerParamList, 'InnerHome'>) {
  return (
    <View style={styles.inner}>
      <Text style={styles.innerText}>{route.params.label}</Text>
    </View>
  );
}

function InnerStack({ label }: { label: string }) {
  return (
    <View style={styles.innerHost}>
      <Inner.Navigator screenOptions={{ headerShown: false }}>
        <Inner.Screen
          name="InnerHome"
          component={InnerHomeScreen}
          initialParams={{ label }}
        />
      </Inner.Navigator>
    </View>
  );
}

function ModalScreen({
  navigation,
  route,
}: NativeStackScreenProps<RootParamList, 'Modal'>) {
  const { depth } = route.params;

  React.useEffect(() => {
    if (depth >= MODAL_COUNT) {
      console.log(`[RNS4487] settled: ${depth} transparent modals pushed`);
      return;
    }
    const id = setTimeout(
      () => navigation.push('Modal', { depth: depth + 1 }),
      AUTO_PUSH_INTERVAL_MS,
    );
    return () => clearTimeout(id);
  }, [navigation, depth]);

  const step = depth % 8;

  return (
    <View style={styles.transparentFill}>
      <View
        style={[
          styles.card,
          { marginTop: 24 + step * 56, marginLeft: 12 + step * 20 },
        ]}>
        <Text style={styles.cardTitle}>
          transparentModal {depth} / {MODAL_COUNT}
        </Text>
        <InnerStack label={`nested stack @ ${depth}`} />
        <Button title="Pop to Home" onPress={() => navigation.popToTop()} />
      </View>
    </View>
  );
}

export default function App() {
  return (
    <NavigationContainer>
      <Root.Navigator>
        <Root.Screen
          name="Home"
          component={HomeScreen}
          options={{ title: '#4487' }}
        />
        <Root.Screen
          name="Modal"
          component={ModalScreen}
          options={{ presentation: 'transparentModal', headerShown: false }}
        />
      </Root.Navigator>
    </NavigationContainer>
  );
}

const styles = StyleSheet.create({
  home: { flex: 1, padding: 16, gap: 12, backgroundColor: '#fff' },
  title: { fontSize: 20, fontWeight: '700' },
  hint: { fontSize: 13, color: '#555' },
  transparentFill: { flex: 1, backgroundColor: 'transparent' },
  card: {
    alignSelf: 'flex-start',
    minWidth: 220,
    backgroundColor: '#1f6feb',
    padding: 12,
    borderRadius: 10,
    gap: 6,
  },
  cardTitle: { fontSize: 16, fontWeight: '600', color: '#fff' },
  innerHost: { height: 56, borderRadius: 6, overflow: 'hidden' },
  inner: {
    flex: 1,
    backgroundColor: '#ffd166',
    alignItems: 'center',
    justifyContent: 'center',
  },
  innerText: { fontSize: 13, fontWeight: '600', color: '#222' },
});