Mission view can resume to a blank screen #25

New issue

Open

opened 2026-09-13 17:06:07 +00:00 by icub3d · 0 comments

icub3d commented

2026-09-13 17:06:07 +00:00

Owner

Observed once during the Android spike, cause not determined.

After backgrounding the app and relaunching it, the process was still alive with the
same PID and had not crashed, but the screen showed only ClearColor — no UI at all.
Nothing appeared in logcat.

The trigger was KEYCODE_BACK followed by am start, so this may be a state
transition — Escape-to-leave is currently wired as a placeholder — rather than a
rendering or surface fault. Those are very different bugs and the difference matters:
one is a few lines in a state system, the other is Android's classic surface-destroyed-
on-suspend failure.

Investigate

Reproduce deliberately. Compare HOME (background, surface retained) against BACK
(possible state change) against a genuine surface destruction.
Check whether the UI entities still exist and are simply not drawn, or were despawned.
DespawnOnExit(GameState::Mission) and the menu's own despawn rules are the suspects
if it is state.
Check whether bevy_winit recreated the window. The spike's log shows two
winit::platform_impl::android: TODO: warnings on startup — forward onStart notification to application and find a way to notify application of content rect change — which are places winit knows it is not telling the app something.

Done when

The app can be backgrounded and resumed repeatedly and comes back to the screen it left,
with a test or a documented manual procedure that would have caught it.

Observed once during the Android spike, cause not determined. After backgrounding the app and relaunching it, the process was still alive with the same PID and had not crashed, but the screen showed only `ClearColor` — no UI at all. Nothing appeared in logcat. The trigger was `KEYCODE_BACK` followed by `am start`, so this may be a state transition — Escape-to-leave is currently wired as a placeholder — rather than a rendering or surface fault. Those are very different bugs and the difference matters: one is a few lines in a state system, the other is Android's classic surface-destroyed- on-suspend failure. ## Investigate - Reproduce deliberately. Compare HOME (background, surface retained) against BACK (possible state change) against a genuine surface destruction. - Check whether the UI entities still exist and are simply not drawn, or were despawned. `DespawnOnExit(GameState::Mission)` and the menu's own despawn rules are the suspects if it is state. - Check whether `bevy_winit` recreated the window. The spike's log shows two `winit::platform_impl::android: TODO:` warnings on startup — `forward onStart notification to application` and `find a way to notify application of content rect change` — which are places winit knows it is not telling the app something. ## Done when The app can be backgrounded and resumed repeatedly and comes back to the screen it left, with a test or a documented manual procedure that would have caught it.

icub3d added the

labels

2026-09-13 17:06:14 +00:00

icub3d added this to the M1 — Playable Vertical Slice milestone

2026-09-13 17:06:15 +00:00

icub3d referenced this issue

2026-09-13 17:06:28 +00:00

Move from NativeActivity to GameActivity #30