android: avoid OpenSL mixer lock recursion

[kumagi]

What issue is this addressing?

No issue filed yet. Found during an audit of the vendored Oboe sources (Oboe 1.11.0).

What type of issue is this addressing?

bug

What this PR does | solves

In OutputMixerOpenSL::open (internal/oboe/oboe_opensles_OutputMixerOpenSLES_android.cpp), the error path calls close() while mLock is still held by open() itself:

SLresult OutputMixerOpenSL::open() {
    std::lock_guard<std::mutex> lock(mLock);   // mLock held for the whole call
    ...
    goto error;

error:
    close();        // close() takes mLock again
    return result;
}

void OutputMixerOpenSL::close() {
    std::lock_guard<std::mutex> lock(mLock);   // non-recursive -> deadlock
    ...
}

std::mutex is not recursive, so any failure of createOutputMix or Realize deadlocks the calling thread inside open().

The fix

Split the body of close() into closeLocked(), which assumes mLock is already held:

• open()'s error path calls closeLocked() directly.
• close() keeps the same contract and just wraps closeLocked() with the lock.

This mirrors the *Locked naming already used elsewhere in the binding (binding_android.cpp has StartLocked, StopLocked, etc.).

Note: this file is vendored from Oboe 1.11.0 by internal/oboe/gen.go; the same fix would ideally be applied upstream in google/oboe as well.

[hajimehoshi]

We cannot fix Oboe source code directly. If you need, report the issue to github.com/google/oboe