Working theory: This is caused by #51421.

A lot of credit goes both to @gmackall and @reidbaker for offline conversations that led to this issue.

As of today (2024-11-15), different integration tests (in particular, tooling integration tests, if that ends up mattering) are having somewhat significant and currently undiagnosed problems with tests that call (and block on) flutter build apk.

For example:

• Windows tool integration tests are flaky: "Java heap space" #157640
• flutter build "apk" succeeds without libraries from native_assets_without_cbuild_assemble_test.dart is slow and flaky #158560

Three possible things happen that end up leading to failures:

1. The test times out (taking longer than 15m) or the shard times out (taking longer than 30-60m)
2. The test fails due to a Java Heap/OOM
3. The test fails due to (hypothesis) the OS killing Gradle due to low memory

Some things to try:

• Try creating a bringup: true shard where failures happen somewhat consistently to try fixes
• Try adding --verbose to get information about the version of Gradle/Gradle settings being used
• Remove the no-daemon from recipes which doesn't appear to be having any effect/is confusing
• Try using jps to list active Java processes and memory usage between/after tests.
• Try running with double the amount of RAM to see if higher memory lowers flakes significantly

/cc @andrewkolos @bkonyi.