`TransactionTooLargeException` when persisting in-app messages

[empowerRyan]

We're seeing dramatic spikes in crashes caused by TransactionTooLargeExceptions when attempting to save activity state while this SDK is displaying an in-app message.

Fatal Exception: java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 579324 bytes
       at android.app.OurActivity$StopInfo.run(PendingTransactionActions.java:160)
       at android.os.Handler.handleCallback(Handler.java:873)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at android.os.Looper.loop(Looper.java:215)
       at android.app.ActivityThread.main(ActivityThread.java:6939)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:870)

It took a long time to identify the Iterable SDK as the cause because the exception is reported from the Android framework with no useful attribution hints. However we're now confident that the root cause was that we launched some Iterable campaigns which sent in-app messages with abnormally large HTML (>250kb), since turning them off has resulted in a dramatic reduction in crash reports.

We've now spent time going through our Iterable campaigns to ensure that all in-app HTML is a reasonable size (<100kb), but I wanted to suggest some further safeguards you could follow-up with:

1. Stop persisting the HTML upon activity destruction (it's not clear to me where this is happening, though IterableWebView through IterableInAppFragmentHTMLNotification seems a likely culprit)
2. Including a tool in the Iterable web console that warns against in-app messages with HTML above a reasonable size (say 100kb)

[giangpham96]

We also got the same issue. The HTML key in the IterableInAppFragmentHTMLNotification is the issue

[hangduykhiem]

Here's a bundle report from our side

android.os.TransactionTooLargeException: data parcel size 1562860 bytes
Bundle stats: android:viewHierarchyState [size=6400]
    android:views [size=6352]
androidx.lifecycle.BundlableSavedStateRegistry.key [size=1555516]
    android:support:activity-result [size=2368]
    KEY_COMPONENT_ACTIVITY_REGISTERED_KEYS [size=1884]
    android:support:fragments [size=1552692]
        fragment_c66e59a8-1818-45f3-ba84-8aaeb14928a7 [size=10796]
            savedInstanceState [size=10112]
                taco saved state [size=10056]
        fragment_3cec30b1-97d2-4183-9c1b-125ef7feabb0 [size=1540136]
            arguments [size=1538860]
                HTML [size=1538380]
    PersistableBundle stats: [null]

That is 1.5MB of HTML saved as a string in a bundle. As per Google suggestion, this is not the correct way to handle a large amount of data. Please refer to https://developer.android.com/topic/libraries/architecture/saving-states#local

[isimpson]

This is still causing issues in our apps, is there any plan to fix this on the Iterable side?