Siavash Sameni 4250f1b44a step E(android): compile full Oboe C++ bridge (not yet called from Rust) ...

Fifth incremental variable — and the first genuinely heavy one. Adds:
  - cpp/oboe_bridge.{h,cpp} (copied verbatim from crates/wzp-android/cpp/)
  - cpp/oboe_stub.cpp (fallback if Oboe can't be fetched)
  - build.rs now clones google/oboe@1.8.1 into OUT_DIR and compiles
    oboe_bridge.cpp + every .cpp file under oboe/src/ as a single
    static library via cc::Build, using shared libc++. Same logic as
    the legacy wzp-android build.rs.
  - libc++_shared.so gets copied from the NDK sysroot into the Tauri
    gen/android jniLibs directory so the runtime linker can find it.
  - rustc-link-lib=log / OpenSLES emitted for Oboe's Android backends.

Deliberately NOT called from Rust yet — no extern "C" FFI declarations,
no oboe_audio.rs module, the `wzp_oboe_*` symbols from the static lib
are simply present but unreferenced.

Goal: isolate whether the Oboe C++ compile + static lib link alone
(with its libc++ dependency and log/OpenSLES bindings) regresses the
working baseline. If the build still launches and renders the home
screen, we know the C++ side is clean and the actual regression is
caused by calling into Oboe at runtime (next step).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

2026-04-09 15:09:16 +04:00

934 B

Raw Blame History

View Raw