android: fixed-point preload to resolve transitive .so deps#343
Open
leaiss wants to merge 1 commit into
Open
Conversation
…n lib dir PR #333's single-pass preload broke once readdir returned candidates in an order where a dependent .so was visited before its in-bundle deps. Reproduced on Android-36 emulator with the current CNSDK bundle (libblink → libSNPE + liblicense_utils): dlopen failed: library "libleiaSDK-faceTrackingInApp.so" not found: needed by .../libdxrp050_leia_cnsdk.so in namespace clns-7 readdir visited libblink before liblicense_utils → libblink preload failed (transitive dep not yet in soinfo) → libleiaSDK preload failed (needs libblink) → libdxrp050 dlopen failed (needs libleiaSDK). xrCreateInstance regressed to XR_ERROR_INITIALIZATION_FAILED. Fix: iterate the preload loop until a full pass loads nothing new. For our dep depth of ~3, two passes converge. Worst case O(N^2) dlopen attempts for N libs, but N is small (~16) and dlopen of an already-loaded soinfo is essentially free. Final unloaded libs get logged at WARN with the last dlerror for diagnosis (some SNPE DSP .so always fail on non-Qualcomm hardware — libcdsprpc.so missing or 32-bit Skel files — which is fine; they're never reached at runtime on the emulator/Lume Pad load path). Verified on Android-36 x86_64 emulator: xrCreateInstance now reaches XR_SUCCESS again, plug-in leia-cnsdk activates, xrCreateVulkanInstanceKHR succeeds, xrCreateVulkanDeviceKHR hits the expected emulator extension-limit (VK_ERROR_EXTENSION_NOT_PRESENT) — the same wall documented in docs/getting-started/android-emulator-setup.md.
leaiss
force-pushed
the
fix/android-preload-fixed-point
branch
from
d7ff93e to
95eb761
Compare
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.
Summary
Regression fix on top of PR #333. The preload loop in
target_plugin_loader.cdid a single readdir pass — fine if the filesystem visited dependency-leaves first, broken if it didn't. The current CNSDK bundle's deps are:libdxrp050 → libleiaSDK → libblink → libSNPE + liblicense_utils. When readdir visitslibblinkbeforeliblicense_utils, libblink's preload fails (its DT_NEEDED for liblicense_utils can't resolve in the namespace yet), libleiaSDK fails (needs libblink), andlibdxrp050_leia_cnsdk.soultimately fails to dlopen with:This regression silently broke the validation chain on Android-36 emulator —
xrCreateInstancereturnedXR_ERROR_INITIALIZATION_FAILEDinstead of the previously-validatedXR_SUCCESS.Fix
Iterate the preload loop until a full pass loads nothing new. Worst case O(N²) dlopen attempts for N libs, but N is small (~16) and dlopen of an already-loaded soinfo is essentially free. After fixed-point, any libs still unloaded get logged at
WARNwith their last dlerror — useful for diagnosing genuinely broken deps vs. ordering issues.Some SNPE DSP
.sofiles always fail on non-Qualcomm hardware (libcdsprpc.so missing, or 32-bit Skel files); they're never reached at runtime on the main load path, so they're noise in the report rather than blockers.Verification
Android-36 x86_64 emulator (arm64 binary translation), runtime APK + leia-cnsdk plug-in (post bundle-transitive) + cube_handle_vk_android test app:
libdxrp050_leia_cnsdk.sodlopenxrCreateInstancexrCreateVulkanInstanceKHRxrCreateVulkanDeviceKHRSame emulator wall as documented in
docs/getting-started/android-emulator-setup.md.Test plan
:src:xrt:targets:openxr_android:assembleInProcessDebugbuilds clean.preloaded libleiaSDK-faceTrackingInApp.so(etc.) andxrCreateInstance -> XR_SUCCESS.🤖 Generated with Claude Code