Android native: tighten Oboe build, fix getLastError race, cut audio-thread syscalls

[Copilot]

Follow-up to the Oboe/Veldrid integration: apply the deferred optimizations from the previous PR and harden one race-y P/Invoke path discovered on a second pass. No game logic touched.

CMake (osu.Android/Native/CMakeLists.txt)

• Strip -ffast-math from Oboe's compile options (kept on our own bridge). Avoids __FINITE_MATH_ONLY__ symbol-version drift against system libm.
• OBOE_BUILD_TESTS / EXAMPLES / DOCS = OFF and BUILD_TESTING = OFF — FetchContent stops compiling artifacts we never ship.
• GIT_SHALLOW TRUE on the Oboe FetchContent_Declare for faster CI checkout.

Audio bridge (oboe_bridge.{h,cpp})

• Explicit #include <unistd.h> next to <android/performance_hint.h> so gettid() no longer rides on transitive Oboe/NDK includes.
• Throttle updateLatency() to every 256 callbacks while leaving LatencyTuner::tune() at 128 — halves AAudio syscall pressure on the audio thread.
• Fix TOCTOU in nOboeGetLastErrorMessage: previous code returned lastError_.c_str() after releasing the mutex, so a concurrent Oboe error callback could mutate the std::string before the P/Invoke marshaller copied it. getLastError() now returns by value (copy under lock); the C export stages it into a thread_local snapshot whose lifetime covers the marshal step. Managed ABI unchanged.

// oboe_bridge.cpp — race-safe export
OSU_EXPORT const char* nOboeGetLastErrorMessage(intptr_t ptr) {
    auto* bridge = reinterpret_cast<OboeBridge*>(ptr);
    if (!bridge) return nullptr;
    thread_local std::string snapshot;
    snapshot = bridge->getLastError();   // copy under mutex, by value
    return snapshot.empty() ? nullptr : snapshot.c_str();
}

Not touched

vulkan_bridge.cpp (runs once at startup), the C# wrapper, and both submodule forks — none need changes for these wins.

[gitar-bot]

Important

You are using the Gitar free plan. Upgrade to unlock code review, CI analysis, auto-apply, custom automations, and more.

_Gitar

[Copilot]

Pull request overview

This PR optimizes and hardens the Android native audio integration by reducing unnecessary Oboe build work, lowering audio-thread syscall pressure, and fixing a race in the native-to-managed error-message path.

Changes:

• CMake: disable Oboe tests/examples/docs and use shallow FetchContent to speed up CI/build; adjust Oboe compile options to avoid problematic flags.
• Audio callback: throttle updateLatency() to every 256 callbacks while keeping LatencyTuner::tune() at 128.
• Error ABI hardening: make getLastError() return by value (copy under lock) and return a stable thread_local snapshot from nOboeGetLastErrorMessage.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
osu.Android/Native/CMakeLists.txt	Disables non-shipping Oboe artifacts, shallow-fetches Oboe, and patches Oboe compile flags for compatibility.
osu.Android/Native/oboe_bridge.h	Changes getLastError() to return std::string by value with updated contract comment.
osu.Android/Native/oboe_bridge.cpp	Fixes AllowedCapturePolicy enum, reduces audio-thread syscalls, and makes last-error export race-safe via thread_local snapshot.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

<unistd.h> is already included at the top of this file, so the new mid-file #include <unistd.h> is redundant and the “don’t rely on transitive includes” comment is now misleading. Consider removing the duplicate include (and ideally keeping all includes in one place).

Suggested change

	// Explicit dependency for gettid() used in nADPFCreateSession below — do not
	// rely on transitive includes from Oboe / NDK headers, which may change.
	#include <unistd.h>

[Copilot]

oboe_bridge.h uses std::string in the public API (getLastError()) but the header doesn’t explicitly include <string>. It currently works only if a transitive include happens to pull it in; please add #include <string> to make the header self-contained.

[Copilot]

The new comment says “~1.5s @ 192 burst, 48 kHz”, but 128 callbacks * 192 frames / 48kHz is ~0.51s (and the callback frame count may not even be fixed since framesPerDataCallback is unspecified). Please correct or soften the timing estimate to avoid misleading future readers.

Suggested change

	// LatencyTuner once every 128 callbacks (~1.5s @ 192 burst, 48 kHz).
	// Run the LatencyTuner once every 128 callbacks. The wall-clock interval
	// depends on the callback frame count and sample rate (for example, at
	// 192 frames/callback and 48 kHz this is about 0.5s).