docs(android): reconcile preview integration after #273

[besmpl]

Status

Ready to merge at exact head 3a7acf9fa217db2ee2bfd3d7b5223de66f47df30, directly on current WGPU main (93fb27ff7ad717943e870580892b7490961a3ab7). The PR is conflict-free and GitHub reports MERGEABLE / CLEAN. CI run 30080220791 is fully green, including both Android arm64 jobs.

Rebase result

While resolving the requested rebase, I found that #273 had been squash-merged with the complete #268 Android stack still below its typed-surface commits. Its merge commit 93fb27ff7ad717943e870580892b7490961a3ab7 explicitly includes:

• feat(vulkan): add Android arm64 WSI parity;
• ci(android): prove arm64 preview boundaries;
• docs(android): define the Vulkan preview contract;
• test(android): cover API 36 platform policy; and
• build(android): consume canonical goffi v0.6.1.

I verified the result at the tree level: every file changed by #268's Android-owned range (0eb4143..13b59db) is byte-identical between the old #268 head and current main. Replaying those commits would therefore duplicate code that is already merged rather than produce a reviewable Android delta.

The clean rebase is consequently current main plus one focused documentation reconciliation commit. This preserves #268 as the original design/review record without manufacturing a duplicate implementation diff.

What this PR now changes

• records that the Android Vulkan preview is already present on WGPU main through feat(surface): match Rust v29 typed surface targets #273;
• removes obsolete prerequisite/rebase instructions;
• records canonical goffi v0.6.1 as the default backend dependency;
• keeps the optional Rust path pinned to the exact merged webgpu#24 source until a canonical release contains it; and
• keeps the API 29/API 36 physical-device matrix as an explicit release-evidence gate.

Implementation review location

The Android implementation to review is now in merge commit 93fb27f, with the design, ownership, API-floor, and evidence discussion retained in this PR. The relevant implementation remains in hal/vulkan/*android*, hal/vulkan/swapchain*, hal/allbackends/register_android.go, and scripts/check-android-arm64-preview.sh.

Verification

All current GitHub checks pass:

• Android arm64 preview with Go 1.25.12 and Go 1.26.5;
• Linux, macOS, and Windows build and test;
• lint, formatting, dependencies, and GLES/EGL integration.

Focused local verification also passed:

CGO_ENABLED=0 GOWORK=off go list ./... | grep -v '/hal/metal$' | xargs env CGO_ENABLED=0 GOWORK=off go test -count=1
CGO_ENABLED=0 GOWORK=off go list -tags rust ./... | grep -v '/hal/metal$' | xargs env CGO_ENABLED=0 GOWORK=off go test -count=1 -tags rust
GOOS=android GOARCH=arm64 CGO_ENABLED=0 GOWORK=off go test -run '^$' -exec=true ./...

The historical Codecov bot comment predates this rebase and describes the old replay stack. The current PR changes documentation only and introduces no coverable Go lines.

Cross-build and binary-shape proof still do not substitute for representative hardware. API 29 and API 36 arm64 startup, known-color presentation, rotation, Activity recreation, repeated native-window replacement, and representative vendor/device coverage remain release-evidence gates rather than claims made here.

[kolkov]

Thank you for this — the scope and quality of work here is impressive. Rust v29 semantic oracle, ELF dependency audits, dual cgo mode testing, and a clear prerequisite stack show serious engineering.

Before we dive into the review: have you seen our Android research discussion? https://github.com/orgs/gogpu/discussions/31 — it covers the "Minimal CGO Bootstrap" approach and community feedback. Would be good to know if your design aligns with or diverges from what we outlined there.

We will review the full stack (#264–#269, goffi#62, and this PR), but this is 10K+ LOC across multiple repositories touching core lifecycle, surface ownership, and a new platform. We take responsibility for every line that lands in the codebase, so this will take some time to do properly. We'll work through the prerequisites first and come back to the Android implementation after that.

Thanks again for the thorough work and for being upfront about the merge path and remaining physical-device gates.

---

Pinging people who may be interested in Android support or whose review would be valuable:

Team: @lkmavi — 5 prerequisite lifecycle fixes affect all backends including Metal. Your review on surface ownership (#269) especially welcome.

wgpu contributors: @samyfodil @amery — lifecycle/surface changes in prerequisites touch areas you've contributed to.

goffi contributors: @jiyeyuran @tie @pekim — goffi#62 adds Bionic/Android arm64 platform loader. Your perspective on the FFI layer changes welcome.

Android interested (from discussion #31 and #18): @JanGordon @beikege @celer @SideFx — this is an Android implementation candidate. Your input and testing interest welcome.

[kolkov]

One more thought — since you're driving the Android implementation and have hands-on experience with the Go mobile toolchain + NDK, would you be interested in starting a discussion on r/golang about adding mobile platform support to a Pure Go GPU stack? The community there is large and this could attract developers and testers who have Android/iOS devices and experience with Go on mobile. Getting early feedback and testing help from the broader Go community would help us reach enterprise-quality faster.

Just an idea — totally up to you.

[besmpl]

Yes, I read discussion #31. I think this implementation should align with the minimal-bootstrap direction, with one important boundary made explicit.

Purego/goffi can replace cgo for outbound platform and Vulkan calls after startup; it does not replace Android's inbound process-entry/JNI boundary. A conventional Activity-hosted Go library still needs CGO_ENABLED=1 to expose C-callable JNI entry points. Purego itself currently requires cgo on Android arm64, and goffi#62 deliberately rejects callbacks on Android until foreign-thread runtime entry is proven.

The direction I would recommend is therefore two layers:

1. WGPU core owns Android Vulkan/WSI from a caller-supplied ANativeWindow* downward. It should not own an Activity/GameActivity, JNI, input dispatch, packaging, or a particular Android framework. That is the boundary docs(android): reconcile preview integration after #273 #268 currently follows: the display handle is ignored, the host supplies a non-null raw window, WGPU owns the VkSurfaceKHR, and the host retains ownership of its application reference to the native window.
2. A separate minimal Android host/reference sample owns the unavoidable bootstrap. Its small cgo/JNI edge obtains and retains the ANativeWindow*, forwards lifecycle/input events into Go, and uses normal cgo-exported entry points for the inbound calls. From that pointer onward, WGPU/goffi performs the Vulkan work without per-call C wrappers.

I would keep WGPU/goffi buildable in both cgo modes where practical, but describe the modes precisely: cgo-disabled builds are useful library, headless, and toolchain evidence; the standard visible Activity route is currently a cgo-enabled final shared library. This avoids promising that Purego alone can manufacture an Android application entry point.

The reference host should also prove the ownership ordering that matters in practice:

• window created/replaced: retain the new ANativeWindow, then create a new WGPU surface;
• window destroyed: stop acquisition and submission, drain and destroy the old WGPU surface, then release the host reference;
• treat native-window identity as independent from dimensions, since Android can replace a window with another of the same size;
• exercise pause/resume, rotation, Activity recreation, and repeated same-size window replacement on physical API 29 and API 30+ devices.

This keeps WGPU usable beneath GameActivity, gomobile, Ebitengine-style shells, custom embedders, and any future cgo-free host route. I would treat #268 as the reusable GPU layer and the minimal bootstrap as a follow-up example or small companion package, rather than expanding this PR to own Android application hosting.

I am also happy to start the r/golang discussion. I think it will be most productive once there is a small runnable host prototype, so the post can offer a reproducible APK/device test and ask concrete questions instead of debating "Pure Go" in the abstract.

[kolkov]

We did a deep investigation into the CGO barrier on Android — all findings are posted in discussion #31.

TL;DR: there are two blockers for zero-CGO Android — (1) purego's dlopen on Android still requires CGO_ENABLED=1 (the pure-Go dlfcn.go path has !android build tag), and (2) no //go:nativeexport directive to produce C-callable JNI entry points without import "C". The //go:wasmexport precedent (Go 1.24, #65199) shows the Go team is open to non-CGO export mechanisms.

Would you be interested in authoring the Go proposal for //go:nativeexport? You have the deepest hands-on knowledge of the JNI boundary and Android NDK. Hearth + gogpu together make a strong real-world case. We'd back it from our side.

[kolkov]

One more thought related to the CGO barrier discussion above.

Your verification section includes go test -race . ./core ./hal/vulkan — which requires CGO_ENABLED=1 (ThreadSanitizer is C++). On Android arm64 with CGO_ENABLED=0, that command simply doesn't work. This is the same class of CGO dependency we're discussing for dlopen and JNI entry points.

We've been working on eliminating this barrier through a pure-Go race detector. Honestly, this work fell off the radar for a while — the gogpu ecosystem (1.1M+ LOC across 15 repos) consumed all available bandwidth. But now that Android support is on the table, CGO-free race detection becomes directly relevant again — it's one of the three CGO barriers standing between Go and first-class Android support.

Two approaches, actually:

1. Standalone tool (kolkov/racedetector, 46 stars, v0.8.5) — AST-level instrumentation, works today with CGO_ENABLED=0. 359/359 Go official race tests passing. Already validated on this codebase. However, the AST approach has inherent limitations that can't be fully solved outside the runtime: limited struct field coverage, approximate escape analysis (causes some false positives), 65K goroutine cap, and no visibility into compiler optimizations that affect memory access patterns.

2. Runtime integration (kolkov/go-race, fork of golang/go) — this is the real solution. Hooks into compiler-generated runtime.raceread/runtime.racewrite with a pure-Go FastTrack implementation, replacing ThreadSanitizer. Gets escape analysis, struct field precision, and inlining for free because the compiler already does the work. Currently at RaceRead 67.8ns (3.5x vs TSAN), down from 6.9x, targeting <2x. Active Go proposal: golang/go#76786 — reopened by @aclements, with implementation guidance from @randall77 and algorithm review by @dvyukov.

This connects to the broader "CGO-free Go" story — three CGO barriers for Android development:

Barrier	Status	Solution
Race detection (ThreadSanitizer)	Standalone: working / Runtime: in progress	racedetector + go#76786
FFI/dlopen (purego)	In progress	goffi#62 (Bionic loader)
JNI entry points	Proposal needed	//go:nativeexport (go#65199 precedent)

All three are being actively worked on. Together with //go:nativeexport, solving these would make Go a first-class citizen on Android without CGO — and gogpu/wgpu + Hearth would be among the first projects to benefit.

@besmpl — the standalone racedetector can be used in your Android CI matrix right now for basic race coverage (racedetector test ./...). For the runtime integration proposal (#76786), @dvyukov specifically asked for real-world benchmarks on concurrent GPU workloads — your Hearth engine + this Android stack would be an ideal test case. Would you be interested in contributing benchmark data?

@lkmavi — this affects your Metal/macOS work too. Cross-compiled GOOS=darwin GOARCH=arm64 race testing from Linux CI is impossible with TSAN. The standalone tool works today; the runtime integration will make go test -race work natively without CGO on all platforms.

[besmpl]

Yes — I’m interested. I would like to try to close the zero-CGO Android gap upstream, not merely document that it exists.

After checking the current Go 1.26 toolchain, I think strict CGO_ENABLED=0 Activity-hosted Android has three mechanical pieces:

1. Outbound loading and FFI. goffi#62 is already our candidate solution for Bionic dlopen/dlsym and Vulkan calls.

2. Native ABI exports and foreign-thread entry. Something in the //go:nativeexport direction must define the C ABI trampoline, Go runtime initialization, calls arriving on Android-owned threads, permitted types, reentrancy, and panic behavior.

3. Producing the Android shared library. Today this fails before exports are relevant:

   CGO_ENABLED=0 GOOS=android GOARCH=arm64 go build -buildmode=c-shared
   -buildmode=c-shared requires external (cgo) linking, but cgo is not enabled
   

So I agree that //go:wasmexport is a strong design precedent, but a directive alone would not complete the Android path. The proposal needs to cover, or deliberately pair with, cgo-disabled native shared-library output and safe foreign-thread runtime entry.

I’m willing to take a focused upstream spike on this:

• build the smallest Android/arm64 main package with no import "C";
• export one fixed-signature function with a prototype directive/toolchain patch;
• produce a loadable .so under CGO_ENABLED=0;
• load and invoke it from Java/NativeActivity on an Android-owned thread;
• prove runtime initialization, goroutines, GC, repeated calls, and Activity recreation;
• turn the evidence into an exact Go proposal and implementation boundary.

If that spike shows a contained compiler/linker/runtime change, I am willing to implement it and author or co-author the proposal—not just file an aspirational issue. If it reveals a broad runtime redesign likely to consume years, we should say so honestly, publish the evidence, and retain the minimal cgo bootstrap as the practical route. Gogpu backing and review would make the proposal substantially stronger.

This work should run in parallel with #268 rather than block it. The WGPU boundary remains useful either way: accept a caller-owned raw ANativeWindow*, own Vulkan/WSI below that point, and keep Activity/JNI policy outside the GPU module. A future cgo-free host can replace the bootstrap without changing WGPU.

On race detection: I’m also happy to contribute reproducible WGPU/Hearth workloads and benchmark data. Two scope details are worth keeping precise:

• the go test -race . ./core ./hal/vulkan listed in docs(android): reconcile preview integration after #273 #268 is a host-side verification command, not an Android/cgo0 claim;
• stock Go 1.26 reports -race is not supported on android/arm64 even with cgo enabled. Our current Android matrix cross-compiles tests with -exec=true; it does not execute an instrumented Android binary, so genuine Android race evidence still requires a device/emulator execution lane.

The standalone detector can still be valuable as additional host and cgo-disabled coverage, and I’m willing to evaluate it without presenting it as equivalent to stock TSAN or physical-device evidence. I also read @dvyukov’s request as primarily asking for long-running, very-high-concurrency real workloads. Hearth is not a high-QPS server, but it can provide a different useful stress case: concurrent engine scheduling, resource lifetime changes, rendering submission, and repeated Android lifecycle transitions.

So yes: let’s seriously test whether zero-CGO Android can be made real within a bounded upstream change. If it can, I’m in to build it.

[besmpl]

@kolkov — the bounded spike is green. The minimum zero-CGO Android native-entry primitive is real, and the implementation plus repro are now public.

Short version: feasibility is no longer the blocker for the narrow Android/arm64 primitive. Hardening and upstream API/runtime design are. The successful path did not require a general scheduler or GC redesign.

Public, pinned evidence

• Harness, audits, emulator recipe, and evidence: besmpl/go-android-cgo-free-prototype@9033485
• Exact Go toolchain prototype: besmpl/go@d31f0b5, based on official Go e59fbed6
• Clean-room instructions: reproduce the minimum proof
• Full run record and limitations: API 30 ATD evidence
• Hosted source/repository verification: successful run

The Go change is an 18-file prototype, +273/-22, covering the Android/arm64 command policy, compiler export metadata, linker setup, shared-library startup, and foreign-thread runtime entry. The probe deliberately keeps the user ABI tiny: one fixed JNI symbol, primitive register-width values, and a small arm64 assembly adapter. This is evidence for a design, not a proposed final general-purpose API.

What passed

Stock Go 1.26.4 still rejects the control at the expected boundary:

CGO_ENABLED=0 GOOS=android GOARCH=arm64 go build -buildmode=c-shared
-buildmode=c-shared requires external (cgo) linking, but cgo is not enabled

The patched toolchain then built the same package with:

GOOS=android GOARCH=arm64 CGO_ENABLED=0 -buildmode=c-shared

The resulting artifact:

• is an AArch64 ELF shared object;
• dynamically exports Java_dev_besmpl_nativeexport_MainActivity_nativeProbe;
• has no import "C";
• has a Go dependency graph excluding pseudo-package C and runtime/cgo;
• has no crosscall2 text implementation;
• has only libdl.so and libc.so in DT_NEEDED; and
• reproduced SHA-256 1aa8455553e3d233a01f247a632e722d2e4873f291a3629ab17d41789292d0f8.

On an Android 11 / API 30 AOSP ATD arm64 emulator, System.loadLibrary loaded it and ART called it from its main thread and a Java-created worker. Each Go callback allocated, started and joined a goroutine through a channel, and completed an explicit runtime.GC() before returning. Five fresh ordinary-shell processes passed under SELinux enforcing, each with a 30-second timeout:

NATIVEEXPORT_OK main=6f63776d73637f78 worker=7f43472d23030ff8
device: ABI=arm64-v8a API=30
run-app-process-harness: passed

What the emulator taught us

It found three real failures that host compilation could not:

1. cgo-free startup attempted best-effort VMA decoration before a G existed;
2. treating every native-export M like a pthread-created callback M gave raw Go clone a nil stack; and
3. raw Go-created threads inherited the Android loader thread's Bionic TLS and overwrote its Go g slot.

The contained fixes were: guard that pre-G decoration path, distinguish Go-owned M stacks from callback-only M stacks, and use Android/arm64 CLONE_SETTLS with each M's existing TLS storage. After those changes, the focused compiler/cmd-go/linker tests, host runtime tests, Android runtime cross-build, artifact audits, and device runs passed.

This confirms our earlier conclusion: a //go:nativeexport-style directive by itself is not enough. The complete primitive also needs cgo-disabled shared-library output and safe foreign-thread runtime entry.

Honest boundary

This is not yet the complete Activity-hosted claim I outlined earlier. The cheap app_process lane proves ART-owned main/worker entry, process restart, goroutines, allocation, and GC. It does not yet prove:

• Activity/UI-thread entry or Activity recreation;
• simultaneous/reentrant Java callers or repeated same-process stress;
• a physical device, API 29, or other ABIs;
• arbitrary JNI values, panic policy, or a final export type system;
• Android race detection;
• outbound Bionic FFI from goffi#62; or
• a WGPU adapter/surface operation.

So I would call this a contained feasibility proof, not production support.

Reproduce

The linked recipe has the SDK/NDK and headless-emulator details. The core source pins are:

git clone --branch besmpl/android-nativeexport-api30-repro --single-branch \
  https://github.com/besmpl/go-android-cgo-free-prototype.git nativeexport-repro
git -C nativeexport-repro checkout --detach \
  9033485b2ed5b3eff590063494f48d2ab40fc84a

git init patched-go
git -C patched-go remote add origin https://github.com/besmpl/go.git
git -C patched-go fetch --depth=1 origin \
  d31f0b5f978859fd58f811b0c886818f7343d259
git -C patched-go checkout --detach FETCH_HEAD
(cd patched-go/src && ./make.bash)

export NATIVEEXPORT_GOROOT="$PWD/patched-go"
export ANDROID_NDK_HOME=/path/to/android-ndk-r29
export ANDROID_SDK_ROOT=/path/to/android-sdk
# Boot an arm64 API 29+ observer, then:
(cd nativeexport-repro && ./scripts/reproduce-minimum.sh)

My recommended next sequence is:

1. get compiler/linker/runtime eyes on the exact Go patch and reduce it into an upstream proposal boundary;
2. add a minimal APK/Activity lane, concurrent/reentrant entry stress, Activity recreation, and API 29/API 30+ physical-device evidence;
3. define primitive type and panic/reentrancy semantics rather than generalizing the assembly probe prematurely; and
4. only then pair inbound native entry with goffi#62's outbound Bionic calls and one WGPU operation.

This still should not block #268 or move Android hosting policy into WGPU. The raw caller-owned ANativeWindow* boundary remains the right one; this work is the replaceable host/runtime layer above it.

Thank you for pushing on the zero-CGO question, @kolkov. The answer from this first bounded experiment is: yes, the minimum mechanism is implementable; now it needs upstream design review and the missing lifecycle/device matrix.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[besmpl]

@kolkov — thank you for insisting on prerequisite-first review, a minimal host boundary, and Rust-wgpu-shaped API parity. The stack is now in its intended review shape, and every current WGPU check—including patch coverage—is green.

The important integration point is unchanged: please review and merge the prerequisites first; #268 should not merge with their replay commits still attached. I will do the cleanup rebases as each prerequisite lands.

Final review graph

Layer	PR	Exact ready head
drain before device teardown	#264	6acfb1ea1cca1dc14d7ab0902931c678dc13e0a6
fail-closed swapchain lifecycle	#265	eb48db0e7eec4c12eaa87cc998f6ea9e8f348fdd
explicit mock construction	#266	e65bec3c74c56cd07265c055ce6a7ec7fbedc680
surface-qualified adapter selection	#267	63efce782d5cf41dacab761d202da0e3d68ed2da
public/core/HAL surface lifetime	#269	2a069cb1fde942339813efd7199ed305a3a2ca84
Bionic outbound FFI	goffi#62	8ccaae72d877a7af0af4b628bf86e92536e27d88
pure-Go Android Vulkan	#268	041e19e65620a0a554718a712ead544794a863b5
canonical wgpu-native Android source	webgpu#24	08592c9f5916b64dfc70aba9e67a74a764bb3ef5
Rust-v29 typed SurfaceTarget parity	#273	d61c2152ed95a80985ff53b30df7f65fd0431367

The five WGPU prerequisites and goffi#62 are independent candidates and can be reviewed in parallel. After they land and goffi is released, I will drop the five replay sequences from #268 and retain exactly its four Android-owned commits. webgpu#24 can land independently; #273 is replayed last and then retains exactly four parity-owned commits. Original authorship is preserved throughout.

Current proof

• All checks are green on WGPU fix(device): drain GPU work before teardown #264, fix(vulkan): fail closed on swapchain capability and sync errors #265, fix(core): require explicit mock adapter construction #266, feat(vulkan): qualify surface adapters with present queues #267, docs(android): reconcile preview integration after #273 #268, fix(surface): centralize acquisition and teardown ownership #269, and feat(surface): match Rust v29 typed surface targets #273: formatting, lint, dependencies, Linux/macOS/Windows build and test, Linux Mesa GLES/EGL integration, and Codecov patch coverage.
• feat(surface): match Rust v29 typed surface targets #273's final coverage repair raised its patch result from 78.97% to 81.15% against the 80.64% target; the fix is positive typed-target/Linux-routing contract coverage, not a policy exception.
• docs(android): reconcile preview integration after #273 #268 and feat(surface): match Rust v29 typed surface targets #273 both run the Android arm64 gate with Go 1.25.12 and Go 1.26.5. The gate compiles every package, test, and headless example through the applicable pure-Go and Rust paths in cgo0 and cgo1, checks Go/NDK ABI layouts, and audits ELF dependencies against the exact clean goffi#62 and webgpu#24 heads.
• Separate local cgo-free SurfaceView observers also passed on headless arm64 API 29 and API 36 emulators: three fresh app processes per API, nine known-color Vulkan presentations, same-size window replacement, Activity recreation, concurrent entry stress, and ordered teardown. Those runs use pinned unpublished integration fingerprints, so I am treating them as exact local evidence—not yet a fetchable clean-room/current-head or physical-device claim.
• There is no personal module path, committed replace, or committed go.work. Temporary CI workspaces are exact-head assertions only; the end state consumes canonical releases.
• API 29 is the native/install floor and the Rust-matching infinite-acquire case. API 30 through API 36 use the bounded path. API 36 is the downstream Java compile/Play target and newest policy/runtime-observer endpoint—not a fictitious NDK API-36 wrapper target.

The full canonical/replay map and exact reproduction command are now pinned in the #268 and #273 descriptions. The Android check also rejects desktop WSI, glibc sonames, standalone libpthread, GLES, and software fallback from the Android Vulkan artifact.

Boundary and remaining evidence

WGPU owns Vulkan/WSI from a caller-supplied ANativeWindow* downward. Activity, JNI, packaging, input, and nativeexport remain in the host. The caller retains its window reference through Surface.Release; WGPU does not acquire or release it. That keeps this usable under GameActivity, gomobile/Ebitengine-style shells, custom embedders, and a future zero-CGO host without changing the GPU API.

Cross-build, ABI, ELF, emulator, and policy proof still do not equal representative physical-device evidence. API 29/API 36 startup and presentation, rotation, Activity recreation, repeated native-window replacement, and vendor/device coverage remain explicit release gates rather than claims in these PRs.

We need this Android path badly for Hearth, and I am genuinely excited to do whatever follow-through makes it durable here: requested revisions, rebases, additional tests, device runs, and ongoing Android CI. None of the API or implementation is engine-specific, and maintainers should not have to untangle the temporary stack themselves.

[kolkov]

goffi v0.6.1 released — Android arm64 Bionic support is now available as a guarded preview.

Release: https://github.com/go-webgpu/goffi/releases/tag/v0.6.1

This unblocks the next step in the merge path: #268 can now consume the canonical goffi release and drop the temporary CI pin. @besmpl has been added to goffi CODEOWNERS for Android paths.

To be clear on scope: this is a guarded preview (API 29+), not full production Android support. Callbacks are explicitly rejected pending physical-device thread proof. Cross-build, ABI, and ELF gates pass on NDK r29 with Go 1.25.12 and Go 1.26.5 — but physical-device evidence remains the acceptance gate before we advertise Android as supported.

We'll start reviewing the prerequisite stack (#264 → #265 → #266 → #267 → #269) next.

[besmpl]

Thank you — done.

• docs(android): reconcile preview integration after #273 #268 is now at exact head 13b59db954dafd2653e6cb5ce3ea14c022782ad2 and consumes released goffi v0.6.1 directly through go.mod/go.sum.
• The unpublished goffi checkout, SHA assertion, and temporary workspace are gone from the pure-Go Android gate.
• Both Android jobs (Go 1.25.12 and Go 1.26.5), all platform jobs, lint, and Codecov are green.
• feat(surface): match Rust v29 typed surface targets #273 is aligned at exact head 086ecade4e9563d74492c202fd515d6f8dc19314: it also consumes goffi v0.6.1 directly, while only the still-unreleased webgpu#24 helper remains an exact temporary checkout for the optional Rust path. All feat(surface): match Rust v29 typed surface targets #273 checks are green as well.
• The fix(device): drain GPU work before teardown #264/fix(vulkan): fail closed on swapchain capability and sync errors #265/fix(core): require explicit mock adapter construction #266/feat(vulkan): qualify surface adapters with present queues #267/fix(surface): centralize acquisition and teardown ownership #269 code branches remain unchanged, mergeable, and green. Their descriptions now defer to docs(android): reconcile preview integration after #273 #268 for the current integration head/replay map instead of embedding top SHAs that become stale.

I will wait for the planned prerequisite review order and drop/fold replay commits as those changes land rather than rewriting the stack prematurely.

[besmpl]

Follow-up evidence is now consolidated on main in the focused Android reproduction repository: besmpl/go-android-cgo-free-prototype#1 (squash commit 9db3254).

That proof now covers:

• cgo-free Android arm64 outbound FFI through released goffi v0.6.1;
• native Activity entry and lifecycle/relaunch guards;
• real WGPU Android surface creation and teardown;
• API 29, API 30, and target/API 36 build and emulator receipts;
• an API-29-floor Android system-DNS adapter using android_res_nsend, android_res_nresult, and android_res_cancel—not /etc/resolv.conf or a hard-coded DNS server;
• dependency-graph, ELF/JNI, signed-APK, Java-harness, and repository audits.

Scope remains deliberate: the DNS/native-export harness is supporting feasibility and reproduction evidence, not code proposed for the wgpu package. This PR remains focused on the Rust-wgpu-shaped Android Vulkan/surface API and consuming canonical goffi. The proof also records the remaining limits: no fresh physical-device receipt for the new DNS gate, the resolver is explicit rather than a global net.DefaultResolver replacement, and native export/toolchain integration remains separately upstreamable.

@kolkov, this is the stable reproduction behind the Android claims here and the DNS row in discussion #31. All checks on this PR are currently green and it is mergeable; review remains the next gate.

[kolkov]

Progress update: all 5 prerequisites are merged, CI green on each.

PR	Status
#264 (drain)	merged ✅
#265 (fail-closed)	merged ✅
#266 (mock adapter)	merged ✅
#267 (surface adapters)	merged ✅
#269 (surface lifetime)	merged ✅

We also reviewed and approved your other PRs in this session: #253 (MDI), #260 (Metal autorelease), #261 (Metal texture arrays), #263 (Metal ICB). #262 (DX12 state tracker) has request-changes — 5 test expectations need the missing field values, details on the review.

We're currently merging #257, then #260 → #261 and #253 → #263. Once that merge queue finishes, please rebase #268 and #273 onto the updated main. We'll proceed with Android code review after rebase.

Regarding CODEOWNERS: we plan to add you for hal/vulkan/*android* and related Android paths in wgpu, same pattern as goffi. Will confirm when #268 lands.

[kolkov]

All other PRs are now merged — #263 (Metal ICB), #262 (DX12 state tracker), #273 (typed SurfaceTarget). CI green on everything.

#268 is the last one standing. It has merge conflicts across ~39 files from the prerequisite and feature merges — too many for automatic rebase. Could you rebase onto current main when you get a chance? We'll review the Android implementation after rebase.

[besmpl]

@kolkov — the requested rebase is done at 3a7acf9. One important detail surfaced during the rebase: #273’s squash already included the complete #268 Android stack, and a tree audit confirms every Android-owned file from the old #268 head is byte-identical to current main. Replaying those commits would only duplicate code that is already merged, so #268 is now current main plus one documentation-reconciliation commit that records the actual integration status. The PR is MERGEABLE / CLEAN, and all 13 checks—including both Android arm64 jobs and Codecov—are green. Please merge #268 when convenient to land that reconciliation and close the original Android review record. The local Metal private-staging test issue is unrelated to Android/#268 and I am fixing it separately; it is not a blocker here.