Architecture A spike: in-app Android compositor (real XR_DXR_android_surface_binding, async main-thread DP creation, host classloader, AAR <queries><intent>)

[dfattal]

Part of #1031 · ADR-036 D2. The spike that turns Architecture A from "feasible" into "shipping".

Architecture A puts the compositor + vendor DP + one vendor core in the app process — the
Windows shape and the Khronos Android loader's native shape. Its blockers are packaging, not
rendering:

1. XR_DXR_android_surface_binding for real — the app passes its own Surface/ANativeWindow;
   retire the runtime-spawned SurfaceView (oxr_session_gfx_vk_native.c:274-300, the
   "single-app POC") and keep it only as the _hosted fallback. No spec file exists yet.
2. Async main-thread DP creation — CNSDK needs the main Looper pumping (LeiaSDK.java:376),
   so DP creation marshals onto the app main thread via aux_android/android_main_thread and
   must be non-blocking when xrCreateSession itself runs on the main thread; the session
   reports XR_SESSION_STATE_READY once the DP is up.
3. Plug-in-loader host classloader — target_plugin_loader.c's Android branch exposes a
   runtime-APK Context/classloader to plug-ins (mirroring loadClassFromRuntimeApk,
   ipc_client_android.cpp:54-58) so vendor Java glue resolves without the app bundling it.
4. displayxr AAR manifest carries the single
   <queries><intent><action android:name="org.displayxr.action.VENDOR_DISPLAY_SERVICE"/></intent></queries>
   (+ the OpenXR broker provider). Depends on the vendor intent-filter ask (L7) in the vendor
   tracker issue. Also audit comp_vk_native for per-process statics of the
   comp_d3d11_target.cpp kind.

Done-when: one cube fully in-process with the vendor DP, then two apps concurrently; measure the
hop saved vs PoC-0.

[dfattal]

Architecture-A spike — run on NP02J, spike/1037-arch-a-inprocess (runtime 09e0452a6) + displayxr-leia-plugin spike/1037-host-classloader (8bda212)

Headline: A is achievable, and the two packaging blockers (D5 visibility, vendor Java glue) are both solved and demonstrated on hardware. The remaining A-specific blocker is item 1 — the runtime-spawned SurfaceView — and it now has a hard crash to point at.

Step 1 — in-process baseline still works on current main ✅

inProcess runtime + cube with its cnsdk.dir escape hatch, on main @ 71513efab (post-#1033/#1034/#1039):

plugin loader: active plug-in: id=leia-cnsdk … plugin_api=5 probe_order=50
  path=…/openxr_runtime.in_process-…/lib/arm64/libdxrp050_leia_cnsdk.so
XR_DXR_display_info (iface=leia-cnsdk): display=0.2350 x 0.1470 m, pixels=2560x1600, atlas=3840x2560
[Core-Loader] Successfully initialized in-service library
HW_GEO: view=1920x1200 tiles=2x1 atlas=3840x1200 target=1600x2560 canvas=0,0 0x0
HW_DBG_APP: located 2 views (submitting 2, mode 'LeiaSR', tiles 2x1)   [~steady]

Head-tracking binder + BacklightMultiClientControlService bind (panel → 3D) both fine. HW_FACE: listener=0 only because nobody was in front of the camera. Gap confirmed: canvas=0,0 0x0 — the in-process comp_vk_native path has no window-rect feed (the #1033 equivalent).

Step 2a — package visibility ✅ D5 / #1038 L7 proven on a retail OS build

First a correction worth recording: the app never hand-writes the vendor <queries> — sdk-0.10.56.aar's own manifest declares <queries><package com.leia.headtrackingservice/><package com.leialoft.display.config/></queries> and the manifest merger injects them. ADR-025's coupling is transitive from the vendor AAR.

• -PdxrQueriesMode=strip (vendor <package> entries removed, AAR classes kept) → the exact ADR-025 abort:
  JNI DETECTED ERROR IN APPLICATION: JNI GetObjectClass called with pending exception android.content.pm.PackageManager$NameNotFoundException: com.leialoft.display.config → Runtime aborting.
• -PdxrQueriesMode=intent — zero vendor package names (verified in the shipped binary manifest with aapt2 dump xmltree), only <queries><intent><action …/></intent></queries> on actions the vendor services already advertise (com.leialoft.intent.action.SET_CONFIG; HTS only has LOCKED_BOOT_COMPLETED today, which is precisely why L7 asks for org.displayxr.action.VENDOR_DISPLAY_SERVICE) → everything works: getPackageInfo succeeds, Successfully initialized in-service library, head-tracking ClientHello/ServerHello, and explicit-component bindService to BacklightMultiClientControlService still succeeds after intent-query visibility — the one on-device verification D5 called for.

Context: com.leialoft.display.config / com.leia.headtrackingservice are SYSTEM but forceQueryable=false, and cube targetSdk=31, so visibility genuinely applies — the result is not an artefact.

Step 2b — vendor Java glue moved into the runtime APK ✅

Dropping the AAR (-PdxrNoCnsdkAar) fails with the exact expected error and, usefully, names the mechanism:

[_DexClassLoader] dexPath: ".../com.leialoft.display.config/base.apk"
java.lang.ClassNotFoundException: Didn't find class "com/leia/sdk/internal/Plugin" …
[Core-Loader] fallback library: dlopen failed: libleiaCore-impl.so not found

Root cause pinned in CNSDK source: leia/common/android/classLoader.cpp builds the core DexClassLoader with request->android->context.getClassLoader() as the parent. So the injection point is the Context, nothing else.

Fix implemented and green on device:

• runtime: new host-iface slot get_android_class_host_context (carved from reserved[], no ABI bump; XRT_PLUGIN_HOST_HAS_CLASS_HOST_CONTEXT feature macro), implemented in target_plugin_loader.c with Context.createPackageContext(<runtime pkg>, INCLUDE_CODE|IGNORE_SECURITY), runtime package derived from the dir the runtime .so was loaded from. No runtime Java class needed (there is none in-process).
• runtime: inProcess flavor now also carries the CNSDK AAR (outOfProcess already did).
• plug-in: uses it for leia_core_library_load only; the Activity still serves limit_orientations / permission dialogs.

Result: cube APK with 0 com.leia.* classes (dex-verified), 0 vendor .so, 0 vendor package names — weaving through the Leia DP in its own process.

plugin loader: class-host Context for 'org.freedesktop.monado.openxr_runtime.in_process' created
[Core-Loader] Successfully initialized in-service library
HW_GEO: … tiles=2x1 atlas=3840x1200 …   +   located 2 views (mode 'LeiaSR')

Step 3 — main-thread init: not a blocker; the #510 M2 note is over-stated ⚠️

leia_cnsdk_create is already non-blocking (kicks leia_core_init_async, a worker polls leia_core_is_initialized). And measured on device, in-process DP creation runs on tid 9090 ≠ pid 9021 — the native_app_glue android_main thread, not the process main thread — and CNSDK inits fine. So the real requirement is "the calling thread has a prepared ALooper that gets pumped afterwards", which native_app_glue satisfies and a Java-UI-thread xrCreateSession also satisfies. The genuine gap is an app that calls xrCreateSession on a bare pthread render thread (Unity/Unreal shape): no Looper → the #510 M2 hang. android_main_thread_dispatch_init() is today only called from service_target.cpp:158 / diag_target.cpp:119.

Step 4 — window rect in-process: gap, not done ❌

The publisher already exists and is unused in-process: MonadoView.startWindowRectPoll() returns early when surfaceStateListener == null (MonadoView.java:213), and in-process android_custom_surface.cpp:183 uses MonadoView.attachToWindow(...), which never sets a listener (only attachToActivity(activity, listener) does). Sink also exists (android_globals_set_window_screen_rect). Wiring it needs a Java→native hop registered in the app process, which is the known-fragile multi-classloader JNI area (#507) — deliberately not attempted in the time box.

Step 5 — two apps side by side: found a hard Architecture-A crash 🔴

scripts/android-sidebyside.sh needed settings put global enable_freeform_support 1 + force_resizable_activities 1 on this device (both 0 by default; without them am task resize is silently reverted to fullscreen). With them, both tasks staged correctly ([0,60][800,2560] / [800,60][1600,2560]) — and then app A died:

FATAL EXCEPTION: main
java.lang.NullPointerException: Attempt to invoke interface method
  'void android.view.ViewParent.requestTransparentRegion(android.view.View)' on a null object reference
  at android.view.SurfaceView.onAttachedToWindow(SurfaceView.java:294)
  at org.freedesktop.monado.auxiliary.MonadoView.onAttachedToWindow(MonadoView.java:159)

The runtime-spawned SurfaceView is added straight to the WindowManager, so it has no ViewParent — and SurfaceView.onAttachedToWindow dereferences one on the freeform/translucent path. This is issue item 1 turning into a crash: A cannot do multi-window until the app passes its own Surface (real XR_DXR_android_surface_binding) and the runtime-spawned SurfaceView is demoted to the _hosted fallback.

Also observed, matching report §6b: the backgrounded app was frozen (ActivityManager: freezing … com.displayxr.cube_handle_vk_android.b, curAdj>=900, ~10 s debounce). And a note for planning: only one runtime flavor is installable at a time (shared broker authority), so an in-process app and an OOP-satellite app cannot be run against each other in one session — an A/C mixed test needs two devices or a second broker authority.

Productisation checklist (feeds #1037)

• XR_DXR_android_surface_binding for real — app-provided ANativeWindow; retire oxr_session_gfx_vk_native.c:274-300 to the _hosted fallback. Blocking: the NPE above. Spec file still missing.
• get_android_class_host_context — promote from spike: doc it in docs/reference/xrt_plugin_iface.md + plugin-discovery.md; plumb the runtime package name from the Khronos broker instead of parsing the .so path; decide the OOP behaviour (currently returns the service's own package — harmless, but should be an explicit no-op).
• displayxr AAR carrying the single <queries><intent><action org.displayxr.action.VENDOR_DISPLAY_SERVICE/></intent></queries> + the broker provider, so no app author writes it. (Mechanism proven; only the action string waits on the vendor.)
• Async/no-Looper DP creation in comp_vk_native — call android_main_thread_dispatch_init() on the in-process main thread and marshal the DP factory when the caller has no Looper; keep it non-blocking.
• Window-rect feed for comp_vk_native — give the in-process MonadoView a SurfaceStateListener that lands in android_globals_set_window_screen_rect, and call xrt_display_processor_vk_set_window_screen_rect before process_atlas (mirrors comp_multi_system.c:2746). Then per-window Kooima in-process (report §10 item 2's open half).
• Audit comp_vk_native for per-process statics of the comp_d3d11_target.cpp kind.
• Freezer/FGS story for A — a backgrounded DisplayXR app is frozen like any other; decide what "concurrent" means when only one window is foreground on a phone-class WM.
• scripts/android-sidebyside.sh: assert/set enable_freeform_support + force_resizable_activities, and report in-process (no satellite) cleanly instead of satellite=?.

Spike branches are not PR material as-is (gradle spike switches, spike manifests). The host-iface slot + the plug-in change are the cleanly upstreamable half.