2

I have lot of TransactionTooLargeException crash reports in console (interesting is - almost exclusively from older android versions 7.0 & 6.0 - pretty much none from newer androids).

It happens always on this line of code in my JobIntentService:

@Override
protected void onHandleWork(Intent intent) {
   ...
   appWidgetManager.updateAppWidget(id, updateViews);//this line
}

Why it happens, and how to avoid it? Anybody has any experiences? Crash log is here:

Caused by: android.os.TransactionTooLargeException:      
  at android.os.BinderProxy.transactNative (BinderProxy.java)     
  at android.os.BinderProxy.transact (BinderProxy.java:503)     
  at com.android.internal.appwidget.IAppWidgetService$Stub$Proxy.updateAppWidgetIds (IAppWidgetService.java:636)
  at android.appwidget.AppWidgetManager.updateAppWidget (AppWidgetManager.java:474)
  at android.appwidget.AppWidgetManager.updateAppWidget (AppWidgetManager.java:550)
  at my.package.myapp.services.MyJobIntentService.onHandleWork (MyJobIntentService.java:99)
  at android.support.v4.app.JobIntentService$CommandProcessor.doInBackground (JobIntentService.java:392)
  at android.support.v4.app.JobIntentService$CommandProcessor.doInBackground (JobIntentService.java:383)
  at android.os.AsyncTask$2.call (AsyncTask.java:295)
  at java.util.concurrent.FutureTask.run (FutureTask.java:237)
  at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1113)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:588)
  at java.lang.Thread.run (Thread.java:818)
qkx
  • 2,383
  • 5
  • 28
  • 50
  • "Why it happens" -- the `RemoteViews` is too large. "and how to avoid it?" -- try to identify what in the `RemoteViews` that would be so big. Do you have some large bitmap? – CommonsWare Jun 07 '19 at 14:34
  • No bitmaps at all. But I am building widget programatically by adding views within views. I guess that might be it. But weird is it only happens on 7.0 and 6.0, and despite having 10x more installs from newer androids, it doesnt happen there almost at all. Which means incidency on older androids is thousands times higher... – qkx Jun 07 '19 at 15:00
  • The `RemoteViews` structure itself should be pretty small -- bitmaps are the only thing that I can think of that would be particularly large. The transaction limit is 1MB, though that is the total for simultaneous operations. Is this the only `TransactionTooLargeException` that you get, or do you see them in other spots of your app as well? – CommonsWare Jun 07 '19 at 15:07
  • its the only one. Problem is my app is calendar widget (month view) so basically I add dynamically 30-50 days (small square views) inside it, and each day has several views within too (text, indicators of events, etc). There is no other way how to build this kind of view, only programatically. Do you think this might be the problem? – qkx Jun 07 '19 at 15:24
  • Conceivably, though it would surprise me. What you could do as a test is call `writeToParcel()` on the `RemoteViews`, then `marshall()` the `Parcel` and see how big the resulting `byte[]` is. – CommonsWare Jun 07 '19 at 15:33
  • Cant marschall it, it throws RuntimeException "Tried to marshall a Parcel that contained Binder objects". But when I use p.dataSize(), it is 34900. – qkx Jun 07 '19 at 16:06
  • OK, that's well below the 1MB transaction limit, so unless there is some other scenario where your `RemoteViews` is a lot larger, I can't explain your symptoms. In principle, even a transaction that small could be the one that pushes you over the limit, due to other simultaneous outstanding transactions. However, you should then be getting `TransactionTooLargeException` thrown in other areas, as it's not *always* going to be this little block that pushes you over the limit. You are not crashing this way elsewhere, though, so I'm stumped. – CommonsWare Jun 07 '19 at 16:14

0 Answers0