Repository navigation
Conversation
Android destroys an activity and creates a new one in the same process after a configuration change the activity doesn't handle itself, such as a new font size or language, and under the "Don't keep activities" developer option. `activityOnDestroy` quit the app, and the next `activityOnCreate` called `quad_main` again, starting a second app in the process that kept the first one's globals. A macroquad app crashed there, freeing GL objects made under the first app's context. `Destroy` now quits only when the activity is finishing. Otherwise the app keeps running, as it does in the background, and the next activity takes it over: `activityOnCreate` hands its global reference to the render thread, which swaps it into `ACTIVITY` and deletes the old one, so calls such as `setFullScreen` reach the activity on screen. Its surface arrives through the usual `surfaceCreated`, as after a pause. A new app still starts when none is running. A fullscreen app makes the new activity fullscreen in `activityOnCreate`, before its window opens, as `run` does for the first one. Left to the next resume, the switch came after the window opened, and on Android 15 the 3-button navigation bar stayed opaque over the app until it was paused and resumed. The fullscreen flag moves from the render thread's state to an atomic so the UI thread can read it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Android destroys an activity and creates a new one in the same process after a configuration change the activity doesn't handle itself, such as a new font size or language, and with the "Don't keep activities" developer option.
activityOnDestroyquit the app, and the nextactivityOnCreatecalledquad_mainagain, starting a second app in a process that still held the first one's globals. A macroquad app aborts there: in the new render thread, Scudo reportsinvalid chunk state when deallocatingwhile dropping anArc<macroquad::material::GlPipelineGuarded>the first app made under its own GL context.Change
Destroyquits only when the activity is finishing (isFinishing()). When Android is about to recreate it, the app keeps running, as it does in the background.activityOnCreatehands a new activity to the running app instead of starting another. The render thread swaps its global reference intoACTIVITYand deletes the old one, sosetFullScreen,showKeyboard, the clipboard andload_assetreach the activity on screen. Its surface arrives through the usualsurfaceCreated, as after a pause. A new app still starts when none is running, for the first activity or after one finished.activityOnCreate, before its window opens, asrundoes for the first one. Left to the next resume, the switch came after the window opened, and on Android 15 the 3-button navigation bar stayed opaque over the app until it was paused and resumed. The fullscreen flag moves from the render thread's state to an atomic so the UI thread can read it.The Java side is unchanged:
QuadNativekeeps its signatures.Verification
On the Android 15 emulator (API 35, 3-button navigation), with a macroquad game (CHOMP) whose activity doesn't handle font scale or locale changes:
cmd locale set-app-locales, and leaving and reopening the game with "Don't keep activities" on all keep the same process and bring the game back as it was: same screen, same position, undo history intact, input working. The navigation bar stays see-through.cargo clippy --target aarch64-linux-androidadds no warnings.🤖 Generated with Claude Code