Bump maplibre to latest so as to fix SA-427 - #1048
Merged
Merged
Conversation
Consuming Oboe from Gradle requires buildFeatures.prefab = true, and AGP then
validates the prefab metadata of every AAR on the module's classpath - not just
the ones the native build actually consumes. MapLibre 13.4.0+ ships a prefab
package declaring stl=c++_static, which prefab rejects against this app's
-DANDROID_STL=c++_shared with CXX1211, even though our C++ never links against
libmaplibre and has no ABI boundary with it. That was capping MapLibre at 13.3.1.
No STL setting can satisfy that check: the verdict is computed from MapLibre's
declared metadata against our STL family before our own code is considered.
c++_shared and c++_static both hit CXX1211, and "none" fails against Oboe, which
declares c++_shared. Oboe was the only reason prefab was on, so vendoring it the
way Steam Audio already is decouples the native build from every other
dependency's prefab metadata.
Oboe is now app/src/main/jniLibs/<abi>/liboboe.so plus headers in
app/src/main/cpp/oboe/include/, imported by CMake as a SHARED IMPORTED target
mirroring phonon. scripts/update-oboe.sh refreshes them from the version pinned
in libs.versions.toml, which stays the source of truth even though Gradle no
longer resolves it; --check re-downloads and diffs, and runs in CI so the pinned
version and the committed binaries cannot drift apart.
Bumped 1.9.3 -> 1.10.0 while here - it had been held back as untested. The 1.10.0
release notes are purely additive (PCM offload, MMAP policy query, compressed
formats), and nothing AudioMixer uses changed signature.
Also fixed a latent typo in CMakeLists.txt: target_include_directories referenced
${STEAMAUDIO_DIR}/include, a variable that is never set, so it expanded to
"/include". It went unnoticed because the phonon imported target already exports
that include directory, which also makes the entry redundant, so it is removed
rather than corrected.
Note: the audio engine has not been exercised on hardware. The Oboe bump wants a
device run - beacons, TTS, earcons, and the Bluetooth disconnect/reconnect path.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Firebase reported an ANR with the main thread blocked in MapLibreSurfaceView$RenderThread.onWindowResize (:432) from surfaceChanged (:163), while the render thread sat in MapLibreVulkanSurfaceView$VulkanThread.guardedRun (:121). Both park on the same renderThreadManager monitor. onWindowResize loops while !renderComplete && ableToDraw(), and up to 13.4.1 ableToDraw() is just readyToDraw(); the Vulkan render thread only breaks out to draw when readyToDraw() && graphicsSurfaceCreated. The one state satisfying both is readyToDraw() true with graphicsSurfaceCreated false, and nothing can clear it, so the main thread waits forever. graphicsSurfaceCreated is set only on the hasSurface && waitingForSurface transition; a fresh render thread starts with waitingForSurface = false and surfaceCreated() only blocks while it is true, so if the framework delivers surfaceCreated() before the new thread's first loop iteration the transition is missed permanently. The tightest window is MapLibreSurfaceView.onAttachedToWindow, which starts a new render thread mid-traversal. Upstream fixed exactly this in 13.5.0 by overriding ableToDraw() to also test graphicsSurfaceCreated. Confirmed in the resolved artifact rather than the tag: javap shows VulkanThread declaring ableToDraw() in 13.6.0 and not in 13.3.1. Worth recording that nothing here ever asked for the Vulkan renderer. Through 11.x org.maplibre.gl:android-sdk was the OpenGL build; from 13.x the same coordinate is the Vulkan build, so the 11.13.0 -> 13.3.1 bump switched renderers silently. It only became reachable when the map moved from TextureView to SurfaceView, since TextureView never calls surfaceChanged. android-sdk-opengl is the same version on OpenGL, has never had this deadlock, and is the escape hatch if the Vulkan renderer needs backing out. This version was previously unreachable because of the prefab STL conflict resolved in the preceding commit. Note: the Vulkan AAR contributes a required uses-feature for android.hardware.vulkan.version to the merged manifest, which is a hard device requirement on Play. That was already true on 13.3.1, so it is not a regression, but it is now deliberate. Not yet exercised on hardware. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
No description provided.