Qué hacer en TransactionTooLargeException

Esta no es una respuesta definitiva, pero puede arrojar algo de luz sobre las causas de un TransactionTooLargeException y ayudar a identificar el problema.

Aunque la mayoría de las respuestas se refieren a grandes cantidades de datos transferidos, veo que esta excepción se lanza incidentalmente después de un desplazamiento pesado y zoom y repetidamente abrir un menú giratorio de ActionBar. El bloqueo ocurre al tocar la barra de acción. (esta es una aplicación de asignación personalizada)

Los únicos datos que se pasan parecen ser toques del " Despachador de entrada" a la aplicación. Creo que esto no puede ascender razonablemente a cerca de 1 mb en el"Búfer de transacciones".

Mi aplicación se está ejecutando en un dispositivo quad core 1.6 GHz y utiliza 3 hilos para heavylifting, manteniendo un núcleo libre para el hilo de interfaz de usuario. Además, la aplicación utiliza android: largeHeap, tiene 10 mb de montón no utilizado a la izquierda y tiene 100 mb de espacio para crecer el montón. Así que no diría que es un problema de recursos.

El choque siempre está inmediatamente precedido por estas líneas:

W/InputDispatcher( 2271): channel ~ Consumer closed input channel or an error occurred.  events=0x9
E/InputDispatcher( 2271): channel ~ Channel is unrecoverably broken and will be disposed!
E/JavaBinder(28182): !!! FAILED BINDER TRANSACTION !!!

Que son no necesariamente impreso en ese orden, pero (por lo que he comprobado) suceder en el mismo milisegundo.

Y la traza de pila en sí, para mayor claridad, es la misma que en la pregunta:

E/AndroidRuntime(28182): java.lang.RuntimeException: Adding window failed
..
E/AndroidRuntime(28182): Caused by: android.os.TransactionTooLargeException

Profundizando en el código fuente de Android se encuentran estas líneas:

Frameworks/base/core/jni/android_util_Binder.cpp:

case FAILED_TRANSACTION:
    ALOGE("!!! FAILED BINDER TRANSACTION !!!");
    // TransactionTooLargeException is a checked exception, only throw from certain methods.
    // FIXME: Transaction too large is the most common reason for FAILED_TRANSACTION
    //        but it is not the only one.  The Binder driver can return BR_FAILED_REPLY
    //        for other reasons also, such as if the transaction is malformed or
    //        refers to an FD that has been closed.  We should change the driver
    //        to enable us to distinguish these cases in the future.
    jniThrowException(env, canThrowRemoteException
            ? "android/os/TransactionTooLargeException"
                    : "java/lang/RuntimeException", NULL);

A mí me parece que posiblemente estoy golpeando esta característica indocumentada, donde la transacción falla por otras razones que una Transacción siendo TooLarge. Le debería haberlo nombrado TransactionTooLargeOrAnotherReasonException.

En este momento no resolví el problema, pero si encuentro algo útil actualizaré esta respuesta.

Actualización: resultó que mi código filtró algunos descriptores de archivo, cuyo número se maximiza en linux (típicamente 1024), y esto parece haber desencadenado la excepción. Así que era un problema de recursos después de todo. Verifiqué esto abriendo /dev/zero 1024 veces, lo que resultó en todo tipo de excepciones extrañas en las acciones relacionadas con la interfaz de usuario, incluida la excepción anterior, e incluso algunos SIGSEGV. Al parecer, la falta de abrir un archivo / socket no es algo que se maneja / informó muy limpiamente en todo Android.

El TransactionTooLargeException nos ha estado plagando durante aproximadamente 4 meses, ¡y finalmente hemos resuelto el problema!

Lo que estaba sucediendo era que estamos usando un FragmentStatePagerAdapter en un ViewPager. El usuario navegaría y crearía más de 100 fragmentos (es una aplicación de lectura).

Aunque manejamos los fragmentos correctamente en destroyItem(), en Androides implementación de FragmentStatePagerAdapter hay un error, donde se mantiene una referencia a la siguiente lista:

private ArrayList<Fragment.SavedState> mSavedState = new ArrayList<Fragment.SavedState>();

Y cuando el Androide FragmentStatePagerAdapter intenta guardar el estado, llamará a la función

@Override
public Parcelable saveState() {
    Bundle state = null;
    if (mSavedState.size() > 0) {
        state = new Bundle();
        Fragment.SavedState[] fss = new Fragment.SavedState[mSavedState.size()];
        mSavedState.toArray(fss);
        state.putParcelableArray("states", fss);
    }
    for (int i=0; i<mFragments.size(); i++) {
        Fragment f = mFragments.get(i);
        if (f != null && f.isAdded()) {
            if (state == null) {
                state = new Bundle();
            }
            String key = "f" + i;
            mFragmentManager.putFragment(state, key, f);
        }
    }
    return state;
}

Como puede ver, incluso si administra correctamente los fragmentos en la subclase FragmentStatePagerAdapter, la clase base aún almacenará un Fragment.SavedState por cada fragmento que se haya creado. El TransactionTooLargeException se produciría cuando esa matriz se volcó a un parcelableArray y al sistema operativo no le gustaría que 100+ elementos.

Por lo tanto, la solución para nosotros fue anular el método saveState() y no almacenar nada para "states".

@Override
public Parcelable saveState() {
    Bundle bundle = (Bundle) super.saveState();
    bundle.putParcelableArray("states", null); // Never maintain any states from the base class, just null it out
    return bundle;
}

Para aquellos que amargamente decepcionados en busca de respuesta de por qué aparece la TransactionTooLargeException, intente verificar lo que guarda en estado de instancia.

En compile / targetSdkVersion sobre el gran tamaño del estado guardado, pero nada se bloquea:

E/ActivityThread: App sent too much data in instance state, so it was ignored
    android.os.TransactionTooLargeException: data parcel size 713856 bytes
    at android.os.BinderProxy.transactNative(Native Method)
    at android.os.BinderProxy.transact(Binder.java:615)
    at android.app.ActivityManagerProxy.activityStopped(ActivityManagerNative.java:3604)
    at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3729)
    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:6044)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)

Pero en compile / targetSdkVersion> = 24 tenemos real RuntimeException crash en este caso:

java.lang.RuntimeException: android.os.TransactionTooLargeException: data parcel size 713860 bytes
    at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3737)
    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:6044)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
 Caused by: android.os.TransactionTooLargeException: data parcel size 713860 bytes
   at android.os.BinderProxy.transactNative(Native Method)
   at android.os.BinderProxy.transact(Binder.java:615)
   at android.app.ActivityManagerProxy.activityStopped(ActivityManagerNative.java:3604)
   at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3729)
   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:6044) 
   at java.lang.reflect.Method.invoke(Native Method) 
   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865) 
   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755) 

Qué hacer?

Guardar datos en local base de datos y mantener solo ID en estado de instancia que se puede utilizar para recuperar estos datos.

Si necesita investigar qué Paquete está causando su bloqueo, debería considerar probar TooLargeTool.

(Encontré esto como un comentario de @Max Spencer bajo la respuesta aceptada y fue útil en mi caso.)

No hay una causa específica de este problema.Para mí, en mi clase de Fragmentos estaba haciendo esto:

public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    super.onCreateView(inflater, container, savedInstanceState);
    View rootView = inflater.inflate(R.layout.snacks_layout, container); //<-- notice the absence of the false argument
    return rootView;
}

En lugar de esto:

View rootView = inflater.inflate(R.layout.softs_layout, container, false);

Esta excepción generalmente se lanza cuando la aplicación se envía a un segundo plano.

Así que he decidido usar el método de fragmento de datos para eludir completamente el ciclo de vida onSavedInstanceStae. Mi solución también maneja estados de instancia complejos y libera memoria LO antes posible.

Primero he creado un Fargment simple para almacenar los datos:

package info.peakapps.peaksdk.logic;
import android.app.Fragment;
import android.app.FragmentManager;
import android.os.Bundle;

/**
 * A neat trick to avoid TransactionTooLargeException while saving our instance state
 */

public class SavedInstanceFragment extends Fragment {

    private static final String TAG = "SavedInstanceFragment";
    private Bundle mInstanceBundle = null;

    public SavedInstanceFragment() { // This will only be called once be cause of setRetainInstance()
        super();
        setRetainInstance( true );
    }

    public SavedInstanceFragment pushData( Bundle instanceState )
    {
        if ( this.mInstanceBundle == null ) {
            this.mInstanceBundle = instanceState;
        }
        else
        {
            this.mInstanceBundle.putAll( instanceState );
        }
        return this;
    }

    public Bundle popData()
    {
        Bundle out = this.mInstanceBundle;
        this.mInstanceBundle = null;
        return out;
    }

    public static final SavedInstanceFragment getInstance(FragmentManager fragmentManager )
    {
        SavedInstanceFragment out = (SavedInstanceFragment) fragmentManager.findFragmentByTag( TAG );

        if ( out == null )
        {
            out = new SavedInstanceFragment();
            fragmentManager.beginTransaction().add( out, TAG ).commit();
        }
        return out;
    }
}

Luego, en mi actividad principal, evito el ciclo de instancia guardado por completo y defiendo la respoinbility a mi Fragmento de datos. No hay necesidad de usar esto los Fragmentos mismos, sice su estado se añade al estado de la Actividad automáticamente):

@Override
protected void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);

    SavedInstanceFragment.getInstance( getFragmentManager() ).pushData( (Bundle) outState.clone() );
    outState.clear(); // We don't want a TransactionTooLargeException, so we handle things via the SavedInstanceFragment
}

Lo que queda es simplemente hacer estallar la instancia guardada:

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(SavedInstanceFragment.getInstance(getFragmentManager()).popData());
}

@Override
protected void onRestoreInstanceState(Bundle savedInstanceState) {
    super.onRestoreInstanceState( SavedInstanceFragment.getInstance( getFragmentManager() ).popData() );
}

Detalles completos: http://www.devsbedevin.com/avoiding-transactiontoolargeexception-on-android-nougat-and-up/

Es importante entender que el búfer de transacciones está limitado a 1 MB, independientemente de las capacidades del dispositivo o la aplicación. Este búfer se utiliza con cada llamada a la API que realice y se comparte entre todas las transacciones que una aplicación está ejecutando actualmente.

Creo que también contiene algún objeto específico como parcelas y tales (Parcel.obtain()), por lo que es importante siempre coincidir cada obtain() con un recycle().

Este error puede ocurrir fácilmente en llamadas API que devuelven una gran cantidad de datos, a pesar de que los datos devueltos es inferior a 1 MB (si otras transacciones todavía están en ejecución).

Por ejemplo, la llamada PackageManager.getInstalledApplication() devuelve una lista de todas las aplicaciones instaladas. Agregar banderas específicas permite recuperar una gran cantidad de datos adicionales. Hacerlo es probable que falle, por lo que se recomienda no recuperar ningún dato adicional y recuperarlos por aplicación.

Sin embargo, la llamada aún puede fallar, por lo que es importante rodearla con un catch y poder volver a intentarlo si es necesario.

Por lo que sé, no hay solución para tal problema excepto volver a intentar y asegurarse de recuperar la menor información posible.

Yo también tengo esta excepción en un Samsung S3. Sospecho 2 causas raíz,

1. tienes mapas de bits que cargan y ocupan demasiada memoria, usa downsizing
2. Tiene algunos elementos de diseño que faltan en las carpetas drawable-_dpi, Android los busca en drawable y los cambia de tamaño, haciendo que su setContentView salte repentinamente y use mucha memoria.

Use DDMS y mire su montón mientras reproduce su aplicación, eso le dará alguna indicación sobre qué setcontentview está creando cuestión.

Copié todos los elementos de diseño en todas las carpetas para deshacerse del problema 2.

El problema está resuelto.

Así que para nosotros era que estábamos tratando de enviar un objeto demasiado grande a través de nuestra interfaz AIDL a un servicio remoto. El tamaño de la transacción no puede exceder 1MB. La solicitud se divide en trozos separados de 512KB y se envía uno a la vez a través de la interfaz. Una solución brutal que sé pero bueno-su Androide: (

Recientemente también me he encontrado con un caso interesante mientras trabajaba con Android Proveedor de Contactos.

Necesitaba cargar fotos de contactos de la base de datos de contactos internos y de acuerdo con la arquitectura del sistema, todos estos datos se entregan mediante consultas al Proveedor de Contactos.

Como funciona como una aplicación separada, todo tipo de transferencia de datos se realiza utilizando el mecanismo de Binder y, por lo tanto, Binder buffer entra en juego aquí.

Mi el error principal fue que No cerré el Cursor con datos de blob obtenidos del Proveedor de Contactos, por lo que la memoria asignada para el proveedor aumentó y esto infló el búfer de Binder hasta que obtuve toneladas de !!!FAILED BINDER TRANSACTION!!! mensajes en mi salida de LogCat.

Así que la idea principal es que cuando trabaje con Proveedores de contenido externos y obtenga Cursor s de ellos, siempre cierre cuando termine de trabajar con ellos.

En mi caso obtengo TransactionTooLargeException como un bloqueo secundario después de que la biblioteca nativa se bloqueara con SIGSEGV. El bloqueo de la biblioteca nativa no se informa, por lo que solo recibo TransactionTooLargeException.

Para mí también fue el FragmentStatePagerAdapter, sin embargo, sobreescribiendo saveState() no funcionó. Así es como lo arreglé:

Al llamar al constructor FragmentStatePagerAdapter, mantenga una lista separada de fragmentos dentro de la clase, y agregue un método para eliminar los fragmentos:

class PagerAdapter extends FragmentStatePagerAdapter {
    ArrayList<Fragment> items;

    PagerAdapter(ArrayList<Fragment> frags) {
        super(getFragmentManager()); //or getChildFragmentManager() or getSupportFragmentManager()
        this.items = new ArrayList<>();
        this.items.addAll(frags);
    }

    public void removeFragments() {
        Iterator<Fragment> iter = items.iterator();

        while (iter.hasNext()) {
            Fragment item = iter.next();
                getFragmentManager().beginTransaction().remove(item).commit();
                iter.remove();
            }
            notifyDataSetChanged();
        }
    }
    //...getItem() and etc methods...
}

Luego en el Activity, guarde la posición ViewPager y llame a adapter.removeFragments() en el método onSaveInstanceState() reemplazado:

private int pagerPosition;

@Override
public void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    //save other view state here
    pagerPosition = mViewPager.getCurrentItem();
    adapter.removeFragments();
}

Por último, en el método onResume() anulado, vuelva a instanciar el adaptador si no es null. (Si es null, entonces el Activity es se abre por primera vez o después de que la aplicación ha sido eliminada por Android, en el que onCreate hará la creación del adaptador.)

@Override
public void onResume() {
    super.onResume();
    if (adapter != null) {
        adapter = new PagerAdapter(frags);
        mViewPager.setAdapter(adapter);
        mViewPager.setCurrentItem(currentTabPosition);
    }
}

Asegúrese de no poner en el objeto Intent datos de gran tamaño. En mi caso, estaba agregando un tamaño de cadena de 500k y luego iniciando otra actividad. Siempre fracasó con esta excepción. Evité compartir datos entre actividades mediante el uso de variables estáticas de actividades: no tienes que enviarlas a Intent y luego sacarlas de ella.

Lo que tenía:

String html = new String();//some string of 500K data.
Intent intent = new Intent(MainActivity.this, PageWebView.class);
//this is workaround - I just set static variable and then access it from another    activity.
MainActivity.htmlBody = timelineDb.getHTMLBodyForTweet(tweet);
//This line was present and it actually failed with the same exception you had.
//intent.putExtra("com.gladimdim.offtie.webview", html);

Tengo esto en mi syncadapter al tratar de BulkInsert un gran ContentValues []. Decidí arreglarlo de la siguiente manera:

try {
    count = provider.bulkInsert(uri, contentValueses);
} catch (TransactionTooLarge e) {
    int half = contentValueses.length/2;
    count += provider.bulkInsert(uri, Arrays.copyOfRange(contentValueses, 0, half));
    count += provider.bulkInsert(uri, Arrays.copyOfRange(contentValueses, half, contentValueses.length));
}

Encontré la causa raíz de esto (tenemos tanto "adding window failed" como file descriptor leak como dice mvds).

Hay un error en BitmapFactory.decodeFileDescriptor() de Android 4.4. Solo ocurre cuando inPurgeable y inInputShareable de BitmapOptions se establecen en true. Esto causa muchos problemas en muchos lugares interactuar con los archivos.

Tenga en cuenta que el método también se llama desde MediaStore.Images.Thumbnails.getThumbnail().

Universal Image Loader se ve afectado por este problema. Picasso y Glide parece ser que no afectar. https://github.com/nostra13/Android-Universal-Image-Loader/issues/1020

También me enfrentaba a este problema para los datos de mapa de bits que pasan de una actividad a otra, pero hago una solución al hacer que mis datos como datos estáticos y esto está funcionando perfecto para mí

En la actividad primero:

public static Bitmap bitmap_image;

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_first);
   bitmap_image=mybitmap;
}

Y en la segunda actividad :

 @Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_second);
   Bitmap mybitmap=first.bitmap_image;
}

Una solución sería que la aplicación escribiera la ArrayList (o cualquier objeto que esté causando el problema) en el sistema de archivos, luego pasara una referencia a ese archivo (por ejemplo, filename/path) a través de la Intent al IntentService y luego dejara que IntentService recuperara el contenido del archivo y lo convirtiera de nuevo en una ArrayList.

Cuando el IntentService haya terminado con el archivo, debe eliminarlo o devolver la instrucción a la aplicación a través de una transmisión local para eliminar el archivo que creó (devolviendo la misma referencia de archivo que se le proporcionó).

Para más información ver mi respuesta a este problema relacionado.

Como Intents, Proveedores de Contenido, Messenger, todos los servicios del sistema como Teléfono, Vibrador, etc. utilice el proveedor de infraestructura IPC de Binder.Además, las devoluciones de llamada del ciclo de vida de la actividad también utilizan esta infraestructura.

1MB es el límite total de todas las transacciones binder ejecutadas en el sistema en un momento determinado.

En caso de que haya muchas transacciones sucediendo cuando se envía la intent,puede fallar aunque los datos adicionales no sean grandes. http://codetheory.in/an-overview-of-android-binder-framework /

Cuando estoy tratando con el WebView en mi aplicación sucede. Creo que está relacionado con addView y los recursos de interfaz de usuario. En mi aplicación agrego un poco de código en WebViewActivity como este a continuación, entonces se ejecuta bien:

@Override
protected void onDestroy() {
    if (mWebView != null) {
        ((ViewGroup) mWebView.getParent()).removeView(mWebView);  
        mWebView.removeAllViews();  
        mWebView.destroy();
    }
    super.onDestroy();
}

Con tantos lugares donde TransactionTooLargeException puede suceder here aquí hay una novedad más en Android 8 a un bloqueo cuando alguien simplemente comienza a escribir en un EditText si el contenido es demasiado grande.

Está relacionado con el AutoFillManager (nuevo en API 26) y el siguiente código en StartSessionLocked():

    mSessionId = mService.startSession(mContext.getActivityToken(),
            mServiceClient.asBinder(), id, bounds, value, mContext.getUserId(),
            mCallback != null, flags, mContext.getOpPackageName());

Si entiendo correctamente, esto llama al servicio de autocompletar passing pasando el autocompletarmanagerclient dentro del binder. Y cuando el EditText tiene un montón de contenido, parece causar el TTLE.

Algunas cosas pueden mitigarlo (o hacer lo que estaba probando de todos modos): Agregue android:importantForAutofill="noExcludeDescendants" en la declaración de diseño xml de EditText. O en código:

EditText et = myView.findViewById(R.id.scriptEditTextView);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    et.setImportantForAutofill(View.IMPORTANT_FOR_AUTOFILL_NO_EXCLUDE_DESCENDANTS);
}

Una 2da y terrible solución alternativa también podría ser anular los métodos performClick() y onWindowFocusChanged() para detectar el error en una subclase TextEdit. Pero no creo que eso sea sabio en realidad...

Para mí TransactionTooLargeException ocurrió cuando traté de enviar imagen de mapa de bits grande de una actividad a otra a través de intent. Resolví este problema usando Variables globales de la aplicación.

Por ejemplo, si desea enviar una imagen de mapa de bits grande desde una actividad A a to activity B , almacene esa imagen de mapa de bits en la variable global

((Global) this.getApplication()).setBitmap(bitmap);

Luego inicie la actividad B y lea desde la variable global

Bitmap bitmap = ((Global) this.getApplication()).getBitmap();

Tuve el mismo problema al transferir (enviar broadcast) un objeto de mapa de bits a un receptor de broadcast.

intent.putExtra("image", bitmapImage); 

Así que En lugar de enviarlos como mapa de bits. Convertí el mapa de bits en matriz de bytes. Para mi sorpresa funcionó!!! Me pregunto por qué Android no permite transferir datos enormes con mapa de bits, pero permite lo mismo a través de matriz de bytes.

 intent.putExtra("imageInByteArray", convertBitmapToByteArray(bitmapImage)); 

En el receptor convertí la matriz de bytes en mapa de bits y esto resolvió mi problema.

Esta línea de código en el método writeToParcel(Parcel dest, int flags) me ayudó a deshacerme de TransactionTooLargeException.

dest=Parcel.obtain(); 

Después de este código solo estoy escribiendo todos los datos al objeto de parcela es decir dest.writeInt() etc.

Intenta usar EventBus o ContentProvider como solución.

Si está en el mismo proceso(normalmente todas sus actividades lo estarían), intente usar EventBus, ya que en el proceso el intercambio de datos NO necesita un búfer, por lo que no necesita preocuparse por que sus datos sean demasiado grandes. (Solo puede usar la llamada al método para pasar datos de hecho, y EventBus oculta las cosas feas) Aquí está el detalle:

// one side
startActivity(intentNotTooLarge);
EventBus.getDefault().post(new FooEvent(theHugeData));

// the other side
@Subscribe public void handleData(FooEvent event) { /* get and handle data */ }

Si los dos lados de la Intención no están en el mismo proceso, intente algo ContentProvider.

Véase TransactionTooLargeException

La transacción de Binder falló porque era demasiado grande.

Durante una llamada a procedimiento remoto, los argumentos y el valor devuelto de la llamada se transfieren como objetos de Parcela almacenados en el búfer de transacciones de Binder. Si los argumentos o el valor devuelto son demasiado grandes para caber en el búfer de transacción, entonces la llamada fallará y se lanzará TransactionTooLargeException.

Me enfrenté con el mismo problema cuando traté de enviar mapa de bits a través de Intent y, al mismo tiempo, cuando sucede, doblé la aplicación.

Cómo se describe en este artículo ingrese la descripción del enlace aquí sucede cuando una Actividad está en proceso de detenerse, eso significa que la Actividad estaba tratando de enviar sus Paquetes de estado guardados al sistema operativo para guardarlos para restaurarlos más tarde (después de un cambio de configuración o muerte del proceso) pero que uno o más de los Paquetes demasiado grande.

Lo resolví a través de hack al anular onaveinstancestate en mi actividad:

@Override
protected void onSaveInstanceState(Bundle outState) {
    // super.onSaveInstanceState(outState);
}

Y comentario call super. Es un truco sucio, pero está funcionando perfectamente. Mapa de bits se envió correctamente sin bloqueos. Espero que esto ayude a alguien.

Recibí una TransactionTooLargeException de un error de Stackoverflow en una prueba de Android Espresso. Encontré el seguimiento de la pila de errores de stackoverflow en los registros cuando quité el filtro Logcat para mi aplicación.

Supongo que Espresso causó la excepción TransactionTooLargeException al tratar de manejar una excepción realmente grande stacktrace.

Ha borrado su antiguo estado de instancia del método onaveinstancestate, y funcionará bien. Estoy usando FragmentStatePagerAdapter para mi viewpager, así que mantengo el método Override debajo en mi actividad padre para borrar InstanceState.

@Override
protected void onSaveInstanceState(Bundle InstanceState) {
             super.onSaveInstanceState(InstanceState);
             InstanceState.clear();
}

Encontré esta solución desde aquí android.operativo.TransactionTooLargeException on Nougat

Se puede usar:

android:largeHeap="true"

En el manifiesto de Android bajo la etiqueta de aplicación.

Esto resolvió el problema en mi caso!

Otra posible causa:

Tuve una actividad que se estaba iniciando en onResume()! Esto resulta en un montón de transacciones y hace que el teléfono (Galaxy S2) se congele completamente (sin ANR ni nada) y luego se restablezca, lo que es una especie de gran error en sí mismo.

Sería interesante ver lo que sucede en otros teléfonos con este código:

class MyActivity extends Activity
{
  // ...
  @Override
  void onResume()
  {
     super.onResume()
     startActivity(new Intent(this, MyActivity.class));
  }
}