Android Question [Solved] Transaction too large crash

[jmon]

Hello,

I have a crash that happens on several devices:

Fatal Exception: java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 604668 bytes
at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3776)
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:6123)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:757)

Now, I'm quite certain to know why that happens. I have a list contaning about 25.000 items (list of types), and that's probably what causes the crash.
This list is built from an SQLite database, and is quite slow to generate this list.

The insight in Crashlytics tells me that the object is bigger than 1Mb and that causes the crash:

This exception occurs when too much data is transferred via Parcels concurrently. The underlying Binder transaction buffer has a limited fixed size, currently 1Mb, which is shared by all transactions in progress for the process. Consequently this exception can be thrown when there are many transactions in progress even when most of the individual transactions are of moderate size. For example, `intent.putExtra(key, new LargeParcelableObject())` where the size of the `LargeParcelableObject` exceeds 1Mb will return in this exception. This is often seen when transferring bitmaps between Activities, or when saving a large amount of state between Activity configuration changes. For more information, check out the resources below.

I imagine, from the insight, that the list (which is a process_global list) cannot be saved when the app goes on pause?

Do I understand the problem correctly? What would be the best way to dump and restore this list as fast as possible when the activity goes resume?

Thank you for your support.

Jmon

Edit: I don't think that the error comes from SQLite, because I retrieve the results with a limit of 1000 items at a time, with a timer.

Edit: Solved in post #7

 

[Computersmith64]

Errrr - why are you trying to save/restore a list of 25,000 items? If I read the rest of your post correctly, these items are coming from an SQLite DB, so why don't you just reload the list from the DB when the app resumes?

- Colin.

 

[DonManfred]

I don't think that the error comes from SQLite

Sqlite has a Transactionlimit of 1 MB.
So, yes, the error come from SQLite.
you can overcome this when you read less items at once. Read 100, 1000 Items and when you need more, reload them using lazyloading.

 

[jmon]

so why don't you just reload the list from the DB when the app resumes?

Yes, I was trying to avoid that, because reading from the DB and building the list takes a few seconds. I want the app to be as responsive as possible

Read 100, 1000 Items and when you need more, reload them using lazyloading.

Thanks. I am doing that already (edit: I mean that's why I don't think the error comes from there). At first I thought the problem was there, so I implemented that, but still have the issue.

I'll test reloading my list each time the app resumes, but I was wondering if there was something better.

 

[Computersmith64]

Yes, I was trying to avoid that, because reading from the DB and building the list takes a few seconds. I want the app to be as responsive as possible

I'll test reloading my list each time the app resumes, but I was wondering if there was something better.

Is there some context / order to these items? Can you group them into relevant "chunks" & only load the ones a user might be interested in seeing? Better yet, if you're loading them into a ListView, load 2 (or 3 or 4) x the visible rows then load more when the user scrolls.

- Colin.

 

[jmon]

Is there some context / order to these items? Can you group them into relevant "chunks" & only load the ones a user might be interested in seeing?

Not really. It's for this app: https://play.google.com/store/apps/details?id=com.jmon.nameexplorer&hl=en_US
I do a lot of computation to find out the order of the suggested names based on what the user inputs. As you could see now, the results are displayed within <1 s after the user inputs a name. From my tests, that was only possible with a list, because I have to go through all the names, and rank them based on my algorithm, for each input. From those results, I generate another list, sorted, with limited number of items, which is lazy-loaded in the listview.

Now this error I posted on the first post, only occurs on some devices (So far, Motorola XT1575 Android 7, LGE LM-X210APM Android 7, Samsung SM-N950U Android 8). It never happens on my test phones.

I'll go through my code and see what could be done to reduce the size of this list, or find an alternative.

Thanks a lot for your help.

 

[jmon]

Thanks everyone for your help.

I found this page: https://issuetracker.google.com/issues/37103380 , which says that this error only happens on devices with Android 7, which is true in my case. Apparently this error was not displayed on earlier android versions but still present.

That put me on the right track. They say this error happens at Activity.onSaveInstanceState(), so at Activity_Pause in our case. I got an Android 7 device, so I did some tests and found out how to reproduce the problem.

In my app, I use xCustomListview, and when the number of items in the listview is more than 500 (edit: I think about 567 items), my app has this crash when going to pause (for example when I switch apps). I have tested and it's not because of the size of the list, but because of the listview. So I fixed the problem by limiting the number of items loaded in my Customlistview to maximum 500 items. That annoys me, but I don't have a choice at this stage. I should use the standard listview instead.

The issue is that there are no way to prevent this error, because it happens after the Activity_Pause, and is not catchable in the IDE. The issue tracker says that this will not be fixed and works as intended.

Another suggested way to fix this problem, is to clear the scrollview before going to pause. Check the number of items in the scrollview, and if it's more than 500, clear it and reload at app_resume.