12

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!

Lior Iluz
  • 26,213
  • 16
  • 65
  • 114
Shirane85
  • 2,255
  • 1
  • 26
  • 38
  • 1
    https://stackoverflow.com/a/52716351/4390987 – ॐ Rakesh Kumar Aug 21 '19 at 05:32
  • https://stackoverflow.com/questions/13093677/android-fragment-android-support-v4-app-fragment-crashing-the-app – Raju Tukadiya Aug 21 '19 at 05:45
  • Possible duplicate of [java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 558780 bytes when navigating between fragment](https://stackoverflow.com/questions/52716060/java-lang-runtimeexception-android-os-transactiontoolargeexception-data-parcel) – Manoj Perumarath Aug 21 '19 at 05:47
  • @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. – Shirane85 Aug 21 '19 at 07:02
  • Maybe you are saving a Bitmap? Maybe you are using aibraey like ImageCropper that persists a Bitmap to the Bundle? – EpicPandaForce Aug 21 '19 at 07:29
  • @EpicPandaForce 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. – Shirane85 Aug 21 '19 at 08:30
  • Well the fragment saved state contains ViewState and you might be saving something there in one of your fragments or their views – EpicPandaForce Aug 21 '19 at 10:53
  • @Shirane85 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 – Besnik May 18 '20 at 16:41
  • @Besnik 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. – Shirane85 May 18 '20 at 19:15
  • @Shirane85 did you find any solution?as i'm having the same problem.i have around 20fragments inside one activity. – Saloni Parikh Jul 16 '20 at 11:10
  • @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. – Shirane85 Jul 17 '20 at 19:33
  • I've answered a similar question here: https://stackoverflow.com/a/73008611/2860701. It may help you. – Alberto Jul 17 '22 at 01:31

1 Answers1

0

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.

Algorithm and Blues
  • 833
  • 8
  • 19