android:support:fragments saved by Activity is getting larger and causing TransactionTooLargeException

Question

I have an Activity which controls several Fragments. The default Fragment is HomepageFragment. When replacing to a different Fragment i always make sure the stack stays flat - meaning only the HomepageFragment stays in the stack and on top of it the current Fragment. For example:

1. Activity opened with HomepageFragment
2. Replace to FragmentA is needed - all is good cause HomepageFragment is the last Fragment
3. Now the stack is HomepageFragment -> FragmentA
4. Replace to FragmentB is needed - first pop the last Fragment on the stack (fragmentA) than replace with FragmentB
5. Now the stack is HomepageFragment -> FragmentB

On production i see many TransactionTooLargeException crashes.

I used TooLargeTool to track where the issue was coming from and I found out that as I switch between fragments in the activity there is a android:support:fragments key in the SaveInstanceState which is getting larger and larger (Exponentially) until the crash occurs.

It seems that even when popping from the stack, some data regarding the original transaction continues to be saved.

Removing it as suggest here is causing the Activity not to restore properly after being killed by th OS.

Is there something wrong with my method of flattening the stack? Is there a better approach? What data exactly is saved under android:support:fragments?

Note: I'm not setting any argument to those fragments. Also, thay save very small data in their saveInstanceState bundle.

Thanks!

Gaskins

https://mcmap.net/q/826478/-java-lang-runtimeexception-android-os-transactiontoolargeexception-data-parcel-size-558780-bytes-when-navigating-between-fragment – Vanlandingham

#13094177 – Carlile

Possible duplicate of java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 558780 bytes when navigating between fragment – Tertia

@ManojPerumarath I'm not transferring any data to those fragments. My scenario is completely different and caused because of some key in the ACTIVITY which is getting larger and larger and only after about 20 fragments it is big enough to crash. Please remove the duplication. – Gaskins

Maybe you are saving a Bitmap? Maybe you are using aibraey like ImageCropper that persists a Bitmap to the Bundle? – Milkwort

@Milkwort no, the data of the Fragments' bundle is very small, the problem is only the android:support:fragments key which is saved in the Activity's bundle. – Gaskins

Well the fragment saved state contains ViewState and you might be saving something there in one of your fragments or their views – Milkwort

@Gaskins any progress? I'm facing the same problem. In my case i'm holding a lot of fragments in the backstack and each has for instance "view state" stored. The sum of all these states leads to the crash – Cocks

@Cocks We changed to entire architecture of the app and the crash amount reduced but not completly. I still have no anser for this, seems like it grows for some meta data the activity is saving even when you change lots of fragment and remove them from the stack. To me that seems jjust like a bug in Activity until proved otherwise. – Gaskins

@Gaskins did you find any solution?as i'm having the same problem.i have around 20fragments inside one activity. – Paulson

@SaloniParikh I'm afraid not, we ended up refactoring the entire architecture due to big product changes and now we manage the stack entirely different so the issue is not relevant anymore. But let me know if you figured it out. – Gaskins

I've answered a similar question here: https://mcmap.net/q/98498/-what-to-do-on-transactiontoolargeexception. It may help you. – Alban

Answer 1

I did some debugging via supportFragmentManager.registerFragmentLifecycleCallbacks in my Activity, overriding and setting a breakpoint in onFragmentSaveInstanceState.

So it seems that the android:support:fragments Bundle includes

1. Saved states from ViewModels (SavedStateHandle)
2. Navigation args for Fragments on the back stack

In my case the culprit was a custom Parcelable that could grow to several hundreds of kB. With multiple of those on the back stack and in SavedStateHandles the app would cross the 1MB threshold and crash.

I solved the problem by passing just the ID for that Parcelable and loading it from my Repository. A slight hit on performance, but no more crashes.

Commentate