android.os.TransactionTooLargeException

[kelset]

Is this a bug report?

Yes

Have you read the Contributing Guidelines?

Yes

Environment

1. react-native -v: react-native-cli: 2.0.1, react-native: 0.46.4
2. node -v: v8.2.1
3. npm -v: v5.3.0
4. yarn --version: 0.27.5

Then, specify:

• Target Platform: iOS, Android

• Development Operating System: macOS

• Build tools: XCode & Android Studio

The issue is related to Android 7.

Steps to Reproduce

Don't really know.

Expected Behavior

Not crashing.

Actual Behavior

Fabric reports that a few users, all running Android 7 devices, experience this crash (1 time each user):

Fatal Exception: java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 688376 bytes
       at android.app.ActivityThread$StopInfo.run(ActivityThread.java:4211)
       at android.os.Handler.handleCallback(Handler.java:751)
       at android.os.Handler.dispatchMessage(Handler.java:95)
       at android.os.Looper.loop(Looper.java:154)
       at android.app.ActivityThread.main(ActivityThread.java:6688)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1468)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1358)
Caused by android.os.TransactionTooLargeException: data parcel size 688376 bytes
       at android.os.BinderProxy.transactNative(Binder.java)
       at android.os.BinderProxy.transact(Binder.java:628)
       at android.app.ActivityManagerProxy.activityStopped(ActivityManagerNative.java:4132)
       at android.app.ActivityThread$StopInfo.run(ActivityThread.java:4203)
       at android.os.Handler.handleCallback(Handler.java:751)
       at android.os.Handler.dispatchMessage(Handler.java:95)
       at android.os.Looper.loop(Looper.java:154)
       at android.app.ActivityThread.main(ActivityThread.java:6688)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1468)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1358)

And I have no clue what this issue is caused by; I think it's related to the new react-native version, since the crash is only present in the new version of our app ( the previous version was running 0.45). Another change between this version and the previous is that we upped Android's build to use compileSdkVersion 25, buildToolsVersion '25.0.2' .

I couldn't find any report of this issue so I'm opening this issue.

Reproducible Demo

(don't know what causes the issue)

[hey99xx]

Another change between this version and the previous is that we upped Android's build to use compileSdkVersion 25, buildToolsVersion '25.0.2'.

It is likely this point that causes the crash, so it's not really about react-native. On Android Nougat, this is one of the new behaviors https://developer.android.com/about/versions/nougat/android-7.0-changes.html#other

Many platform APIs have now started checking for large payloads being sent across Binder transactions, and the system now rethrows TransactionTooLargeExceptions as RuntimeExceptions, instead of silently logging or suppressing them. One common example is storing too much data in Activity.onSaveInstanceState(), which causes ActivityThread.StopInfo to throw a RuntimeException when your app targets Android 7.0.

Also see https://stackoverflow.com/questions/39098590/android-os-transactiontoolargeexception-on-nougat

[stephenfromrobin]

Any ideas on what can be done about this?

@hey99xx -maybe you have a suggestion?

[kelset]

It is likely this point that causes the crash, so it's not really about react-native.

I agree that it is something related to Nougat, but it also means that react native is not "ready" to handle Android 7.0 properly - reason why I decided to open the issue.

My best guess is that some internals on current react native version are sending large payloads across Binder, so by reporting the issue maybe some cool dev can understand and fix this issue OR provide a workaround ;)

[jgale]

Another change between this version and the previous is that we upped Android's build to use compileSdkVersion 25, buildToolsVersion '25.0.2'.

It is likely this point that causes the crash, so it's not really about react-native. On Android Nougat, this is one of the new behaviors https://developer.android.com/about/versions/nougat/android-7.0-changes.html#other

One thing I wanted to clarify here – according to this extremely helpful post from a Google employee, Picking your compileSdkVersion, minSdkVersion, and targetSdkVersion:

It should be emphasized that changing your compileSdkVersion does not change runtime behavior.

Correct me if I'm wrong, but changing compileSdkVersion to 25 should not cause a crash. However, if the targetSdkVersion was also updated to 25, then you might see this change in behavior. Did you update the targetSdkVersion as well @kelset?

If so, this probably doesn't help you that much since it's still recommended to try and update to targetSdVersion to the latest and test under that platform. If React Native doesn't work well with a with a targetSdVersion of Nougat, that's still a problem that needs to be solved.

(I ask because I'm looking to update compileSdkVersion in my RN app but wasn't brave enough to update targetSdkVersion yet.)

[kelset]

Yes I've updated both compileSdkVersion and targetSdkVersion - so yeah the issue is still there. I doubt that updating both to 26 will fix anything :/

---

EDIT: I've tried updating to 26, let's see what happens.
Moreover, I've found this issue that seems to indicate that it may be related to images, so I'll close the issue here.

[hey99xx]

@kelset For what it's worth, my company's app was getting this exception even without use of RN. So we've switched to using https://github.com/JakeWharton/DiskLruCache to save activity state wherever we needed to workaround this issue.

[dluksza]

This should be reopen. I'm getting this exception on targedSdkVersion 26 and 27 with RN 0.55.4. It is most occurred exception in my app.

Any one have find other solution or workaround?

[kelset]

@dluksza this issue is quite old, and I haven't seen it since. So if you are still experiencing it please open a new issue that follows the template.