ReviewOS

craft-native/craft

Keep Android native activity readiness in its public UI phase budget

#445
Open chris opened this 1 hour ago ·
1 hour ago

The Android checkpoint gate at Craft 0.0.428 failed before any checkpoint operation: https://github.com/craft-native/craft/actions/runs/41503996907/job/125478440353. Retained artifact 13170648252 is 9,621,586 bytes and its archive SHA-256 matches GitHub metadata: b7410a752400252a162c42f7a08259c4cc8ffb810c6987e2bc08904b894dc067.

The actual first-launch command was adb shell am start -W ..., bounded at 10,000 ms. It timed out at 10,009 ms while the cold wrapped Android app process was still binding (the log reaches am_proc_bound only just before that deadline). The native checkpoint UI and interruption model had not started. No checkpoint/runtime pass is inferred.

-W waits for activity drawing inside a command transport deadline, although the fixture separately declares a 30-second public UI readiness phase. Correct that ownership boundary: acknowledge the intent under the unchanged ten-second command cap, then observe the expected owned native UI and exactly one PID. All three observations must share one thirty-second deadline beginning before the intent, instead of accumulating new waits. Record the launch timing and UI identity, and retain the existing four independent process/session checks, pass-through negative control, real rename boundary, complete payload checks, pending acknowledgement, responsive UI and owned cleanup.

Verify the coordinator rejects late UI/PID answers and foreign surfaces, then require a fresh actual Android run before closing. Do not increase command/UI deadlines, add warm-up interactions, retry until green or substitute a successful process launch for checkpoint acceptance.

Related: https://github.com/craft-native/craft/issues/440 https://github.com/craft-native/craft/issues/443 https://github.com/stacksjs/hq.training/issues/318.

Sign in to comment on this issue.