3

I keep getting this error when trying share an image file:

java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 1085992 bytes

I assumed a fix for this would be to compress the image even more and that would lessen the size. Here's the function that does this job:

 public static File saveBitmaptoFile(Bitmap bitmap, File pictureFile) {
    FileOutputStream out = null;
    try {
        out = new FileOutputStream(pictureFile);

        // on the next line I'm trying compress the heck out of image.
        bitmap.compress(Bitmap.CompressFormat.JPEG, 1, out);
    } catch (Exception e) {
        e.printStackTrace();
    } finally {
        try {
            if (out != null) {
                out.close();
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    return pictureFile;
}

Here's the share function:

 private void shareToInstagram() {
        String type = "image/png";
        Intent share = new Intent(Intent.ACTION_SEND);
       //saveBitmpatoFile saves an extremely small and compressed file about 5kb in size

        File pictureFile = ImageUtil.saveBitmaptoFile(photo, ImageUtil.getOutputMediaFile());
        Uri imgUri = FileProvider.getUriForFile(mContext,"com.mycompany.myapp", pictureFile);

        share.setType(type);
        share.putExtra(Intent.EXTRA_STREAM, imgUri);
        mContext.startActivity(Intent.createChooser(share, "Share to"));
    }

I don't understand how, even with such extreme compression applied to the picture file, the TransactionTooLarge error still gets thrown, saying that the parcel size has effectively not changed one bit. What's more is when I select to share the file through gmail I see can that the file size is 5kb; I'm way below the buffer size of 1000kb sited in the docs! Anybody knows what could be causing this error to still be getting thrown?

Error log:

E/JavaBinder: !!! FAILED BINDER TRANSACTION !!!  (parcel size = 1085992)
W/ActivityThread: Bundle stats:
W/ActivityThread:   android:viewHierarchyState [size=3192]
W/ActivityThread:     android:views [size=3088]
W/ActivityThread:   android:support:fragments [size=5516]
W/ActivityThread: PersistableBundle stats:
W/ActivityThread:   [null]
D/AndroidRuntime: Shutting down VM
E/AndroidRuntime: FATAL EXCEPTION: main
              Process: com.myCompany.myApp, PID: 6837
              java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 1085992 bytes
                  at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3950)
                  at android.os.Handler.handleCallback(Handler.java:790)
                  at android.os.Handler.dispatchMessage(Handler.java:99)
                  at android.os.Looper.loop(Looper.java:164)
                  at android.app.ActivityThread.main(ActivityThread.java:6494)
                  at java.lang.reflect.Method.invoke(Native Method)
                  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
                  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
               Caused by: android.os.TransactionTooLargeException: data parcel size 1085992 bytes
                  at android.os.BinderProxy.transactNative(Native Method)
                  at android.os.BinderProxy.transact(Binder.java:764)
                  at android.app.IActivityManager$Stub$Proxy.activityStopped(IActivityManager.java:4623)
                  at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3934)
                  at android.os.Handler.handleCallback(Handler.java:790) 
                  at android.os.Handler.dispatchMessage(Handler.java:99) 
                  at android.os.Looper.loop(Looper.java:164) 
                  at android.app.ActivityThread.main(ActivityThread.java:6494) 
                  at java.lang.reflect.Method.invoke(Native Method) 
                  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438) 
                  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807) 
E/UncaughtException: java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 1085992 bytes
                     at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3950)
                     at android.os.Handler.handleCallback(Handler.java:790)
                     at android.os.Handler.dispatchMessage(Handler.java:99)
                     at android.os.Looper.loop(Looper.java:164)
                     at android.app.ActivityThread.main(ActivityThread.java:6494)
                     at java.lang.reflect.Method.invoke(Native Method)
                     at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
                     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
                  Caused by: android.os.TransactionTooLargeException: data parcel size 1085992 bytes
                     at android.os.BinderProxy.transactNative(Native Method)
                     at android.os.BinderProxy.transact(Binder.java:764)
                     at android.app.IActivityManager$Stub$Proxy.activityStopped(IActivityManager.java:4623)
                     at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3934)
                     at android.os.Handler.handleCallback(Handler.java:790) 
                     at android.os.Handler.dispatchMessage(Handler.java:99) 
                     at android.os.Looper.loop(Looper.java:164) 
                     at android.app.ActivityThread.main(ActivityThread.java:6494) 
                     at java.lang.reflect.Method.invoke(Native Method) 
                     at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438) 
                     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807) 
KarmaDeli
  • 610
  • 1
  • 6
  • 16
  • Does the posted code cause that exception? – greenapps Jan 25 '18 at 23:38
  • @greenapps the error logs says: at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3950), at android.os.Handler.handleCallBack(Handler.java:790), at android.os.Handler.dispatchMessage(Handler.java:99), at android.os.Looper.loop(Looper.java:164) – KarmaDeli Jan 25 '18 at 23:49
  • `Does the posted code cause that exception? ` ? – greenapps Jan 25 '18 at 23:51
  • Your error may be coming from something else, such as the saved instance state `Bundle`. Since we do not have the full Java stack trace, and we do not have the code where you are "trying share an image file", we have no good way of helping. – CommonsWare Jan 25 '18 at 23:52
  • The posted code affects the size of the image I want to share but, no I wouldn’t say this is what’s causing the crash. It’s crashing because the file being shared is somehow still being read as being 1080000 bytes large even though in the app that receives the file, reads said file as being only 5000bytes large. – KarmaDeli Jan 25 '18 at 23:59
  • @CommonsWare I went ahead and added the stack trace and the function that tries to share the picture file, hopefully SO will be better able to assist! Please give it another look – KarmaDeli Jan 26 '18 at 00:33
  • `File pictureFile = ImageUtil.saveBitmaptoFile(photo, ImageUtil.getOutputMediaFile()); `Take that out of `shareToInstagram()`. Do it first. Then call `shareToInstagram()` ` – greenapps Jan 26 '18 at 08:33
  • From where are you calling `shareToInstagram() `? And how often. – greenapps Jan 26 '18 at 08:35
  • In `shareToInstagram()` I see that you use `"image/png"` (which is uncompressed), Can you try changing it to `jpg` and let us know if it changes anything? – Minas Mina Jan 26 '18 at 09:37
  • My guess is that this is coming from the saved instance state `Bundle`. – CommonsWare Jan 26 '18 at 12:03
  • @CommonsWare the saved instance state _Bundle_? I looked into it; it seems that there is a view that is saving the image file and it's somehow trying to pass that arbitrary large file to other applications... Funny, cause I thought my code specified the file I wanted and its size. How do I ignore the saved instance state? – KarmaDeli Jan 26 '18 at 17:07
  • "it's somehow trying to pass that arbitrary large file to other applications" -- no, that is now how the saved instance state `Bundle` works. That `Bundle` is passed to a core OS process, to be able to restore your state if needed and relevant. "How do I ignore the saved instance state? " -- generally, you don't. You fix your `onSavedInstanceState()` method(s) to not put large things in the `Bundle`. I do not know what you mean by "there is a view that is saving the image file". – CommonsWare Jan 26 '18 at 17:14
  • @CommonsWare, the view is saving the image exactly I suppose I misspoke. I'm an iOS developer helping to fix some Android bugs. How can I customize/fix the savedInstanceState so it doesn't put large files in the bundle? I recognize the name from being the argument to the onCreate method in my Activities. I don't know much else about it :/ – KarmaDeli Jan 26 '18 at 17:49

2 Answers2

32

So what it ultimately took resolve this TransactionTooLarge Exception, was to identify the Activity that had its subordinate fragments, views etc adding data parcels to the bundle. Then I ran this code in said Activity:

@Override
protected void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    //Clear the Activity's bundle of the subsidiary fragments' bundles.
    outState.clear();
}

That fixed it for me. Hope this help someone out there!

KarmaDeli
  • 610
  • 1
  • 6
  • 16
  • 1
    I tried different libraries but this Works like a charm.!!! Just one extra line of code. Thanks – Saurabh Kataria May 17 '18 at 09:04
  • 2
    KarmaDeli, did you noticed any side effects? Solution does work with the issue, but it bothers me that I have no idea how it works and what to expect. Have you came upon any related documentation on this matter? – SMGhost Aug 22 '18 at 11:26
  • 1
    Yea, there is some documentation, [link](https://developer.android.com/reference/android/os/TransactionTooLargeException). Essentially what I understand to be happening is this code sees that the individual fragments tied to the activity store data in their own bundles and that the activity's bundle itself doesn't double-down by saving all its fragments' parcels again to its own bundle-- this is what caused the transaction buffer to exceed the 1 mb limit in the first place... No side-effects that I can recall, all views for the activity were held by fragments. – KarmaDeli Aug 22 '18 at 13:55
  • i tried this solution while coming back that activity data is gone .... activity is empty.... – pallavi richhariya Oct 12 '18 at 08:05
  • I'd try putting the method(s) that populate the activity with data in the onCreate method. – KarmaDeli Oct 12 '18 at 11:35
  • @SaurabhKataria i used that line but its removed my activity data ... alll data gone i dnt know how to get it back after clearing.... – pallavi richhariya Oct 12 '18 at 12:37
  • 6
    this is not a fix... this is only a workaround which works if you don't save important thing inside the bundle... This "fix" clean al data inside the bundle that will be saved.. – aeroxr1 May 24 '19 at 15:07
  • @KarmaDeli i am not using onSaveInstanceState method, should i add this method to resolve transaction too large exception , please respond – Erum May 18 '20 at 19:55
  • @Erum sure, but you should consider what aeroxr1 said and adjust for edge cases were this could remove data you need in the bundle. – KarmaDeli May 21 '20 at 03:15
  • For me the error was with the key "com.google.app_measurement.screen_service" – destresa Oct 26 '22 at 02:22
0

Okay, so this answer is quite late, but will surely help someone who is finding a possible solution for TransactionTooLargeException while passing the date between two Activity.

I have already written an answer on how to pass large data from one Activity to Another and the solution uses Shared Preference to store the Bundle and pass it to the other Activity. Here is the answer How to pass large data between two activities

Note: This solution clears the stored Bundle after being read and will not return the Bundle if the Activity is recreated. This is a workaround and any suggestion or issues will be highly appreciated.

Rishabh Sagar
  • 3,877
  • 3
  • 15
  • 24