当我试图通过Intent发送位图时，我也遇到了同样的问题，同时当它发生时，我折叠了应用程序。

当Activity处于停止的过程中，这意味着Activity试图将其保存的状态Bundles发送到系统操作系统，以便以后(在配置更改或进程死亡之后)安全恢复，但它发送的一个或多个Bundles太大了。

我通过重写onSaveInstanceState在我的活动中解决了这个问题:

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

注释调用super。这是一个肮脏的hack，但它是完美的工作。位图成功发送，没有崩溃。 希望这能帮助到一些人。

尝试使用EventBus或ContentProvider之类的解决方案。

如果你在同一个进程中(通常你所有的活动都是)，尽量使用EventBus，因为在进程中数据交换不需要一个缓冲，所以你不需要担心你的数据太大。(你可以只使用方法调用来传递数据，而EventBus隐藏了丑陋的东西) 细节如下:

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

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

如果Intent的双方不在同一个进程中，可以尝试一些ContentProvider。

看到TransactionTooLargeException

Binder事务失败，因为它太大了。 在远程过程调用期间，调用的参数和返回值作为Parcel对象传输，存储在Binder事务缓冲区中。如果参数或返回值太大，无法放入事务缓冲区，则调用将失败，并抛出TransactionTooLargeException。

当我试图bulkInsert一个大ContentValues[]时，我在我的syncadapter中得到了这个。我决定修改如下:

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));
}

This was happening in my app because I was passing a list of search results in a fragment's arguments, assigning that list to a property of the fragment - which is actually a reference to the same location in memory pointed to by the fragment's arguments - then adding new items to the list, which also changed the size of the fragment's arguments. When the activity is suspended, the base fragment class tries to save the fragment's arguments in onSaveInstanceState, which crashes if the arguments are larger than 1MB. For example:

private ArrayList<SearchResult> mSearchResults;

@Override
public void onActivityCreated(Bundle savedInstanceState) {
    super.onActivityCreated(savedInstanceState);

    if (getArguments() != null && getArguments().getSerializable("SearchResults") != null) {
        mSearchResults = (ArrayList) getArguments().getSerializable("SearchResults");
    }
}

private void onSearchResultsObtained(ArrayList<SearchResult> pSearchResults) {

    // Because mSearchResults points to the same location in memory as the fragment's arguments
    // this will also increase the size of the arguments!
    mSearchResults.addAll(pSearchResults);
}

在这种情况下，最简单的解决方案是将列表的副本分配给片段的属性，而不是分配引用:

@Override
public void onActivityCreated(Bundle savedInstanceState) {
    super.onActivityCreated(savedInstanceState);

    if (getArguments() != null && getArguments().getSerializable("SearchResults") != null) {

        // Copy value of array instead of reference
        mSearchResults = new ArrayList((ArrayList) getArguments().getSerializable("SearchResults"));
    }
}

一个更好的解决方案是不要在参数中传递这么多数据。

如果没有这个答案和TooLargeTool的帮助，我可能永远也不会找到这个。

我遇到了相同的问题与ViewPager2和FragmentStateAdapter这里的问题是FragmentStateAdapter标记'saveState()'作为最终和ViewPager2类也是最终的，所以我们不能覆盖的方法，建议在其他答案使现有的答案不适用。

在我的情况下，我能够摆脱事务太大的问题，不保存分页器的状态添加\android:saveEnabled="false" '在XML条目的视图分页器

<androidx.viewpager2.widget.ViewPager2
    android:saveEnabled="false"
    android:id="@+id/viewPager"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent" />

我发现了这个问题的根本原因(我们得到了“添加窗口失败”和文件描述符泄漏mvds说)。

Android 4.4的BitmapFactory.decodeFileDescriptor()有一个bug。 只有当BitmapOptions的inPurgeable和inInputShareable设置为true时才会发生。这在与文件交互的许多地方造成了许多问题。

注意，该方法也是从MediaStore.Images.Thumbnails.getThumbnail()调用的。

通用图像加载器受此问题影响。毕加索和格莱德似乎没有受到影响。 https://github.com/nostra13/Android-Universal-Image-Loader/issues/1020