Repository navigation
android: Only tear down the surface a destroy names - #23
Closed
Bombatomica64 wants to merge 1 commit into
Closed
Bombatomica64 wants to merge 1 commit into
Bombatomica64 wants to merge 1 commit into
Conversation
A SurfaceView's surfaceDestroyed for an old surface can arrive after the replacement surface was already attached (e.g. on Activity recreation). The host then terminated the new window and the app rendered black. Commands now carry the destroyed ANativeWindow; the render thread ignores a destroy that does not match the current surface. Add surface_destroyed_for(window) for hosts that know which surface went away; surface_destroyed() keeps its old meaning. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Author
|
Sorry for the noise. I've combined this into a single PR, #24, so there's only one to review. Closing this one. |
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.
Problem
On the host-driven entry point (
android::host), recreating the Activity in the same process (e.g.FLAG_ACTIVITY_CLEAR_TASK) could leave a black screen with a working app underneath. The new Activity'ssurfaceCreatedcan arrive before the old Activity'ssurfaceDestroyed.SurfaceDestroyedcarried no identity, so the render thread terminated the window that was already attached to the new surface, and nothing re-attached it.The wait in
surface_destroyed()had a related problem: it waited on one sharedSURFACE_RELEASEDflag that a latersurfaceCreatedcould reset, so overlapping destroy/create pairs could time out or return early.Change
Command::SurfaceDestroyed(Option<usize>)carries theANativeWindowbeing destroyed. The render thread callsterm_windowonly if it matchesCURRENT_SURFACE; otherwise it logs and ignores the stale destroy.pub fn surface_destroyed_for(window: &NativeWindow)for hosts that know which surface went away.surface_destroyed()keeps its signature and old meaning (it tears down whatever is attached), and its docs now point to the new function. The module docs recommendsurface_destroyed_for.DESTROYS_REQUESTED/DESTROYS_HANDLED), so each caller waits for its own request. The 2 s bound is unchanged.The
android-activitypath is untouched.Testing
cargo fmt --all,cargo check,cargo ndk -t arm64-v8a check --all-features, andcargo test --lib(46 passed).cargo testdoc tests:platform_viewandplatform_view_elementfail identically onmain, so that failure is not from this change.aarch64-apple-ioswas not checked (Linux machine); the change is Android-only code.surface_destroyed_forfromsurfaceDestroyed. Before the change, an in-process recreation turned the screen black. After it, 5 consecutive in-process recreations all had their late destroys ignored, and rendering, touch and GPUI state stayed intact.Related Kit report: longbridge/gpui-kit#3310
🤖 Generated with Claude Code