ARCore VIO relative-pose precision regressed; gated by `min_apk_version` compatibility level

[jgibson2]

ARCore VIO relative-pose precision regressed; gated by min_apk_version compatibility level

Summary

Recent ARCore (Google Play Services for AR) motion tracking has a regression in
relative-pose precision that breaks multi-view depth / structure-from-motion built on
ARCore poses. Crucially, the behavior is gated by the app's declared
com.google.ar.core.min_apk_version: with the same installed runtime (1.54), declaring
an older compatibility level (≈1.40) yields the older, accurate VIO, while declaring ≈1.44+
(or the client default 242590000 = 1.47) yields a degraded VIO. This strongly suggests
a compat-gated change to the tracking pipeline that regressed.

Global trajectory and rotation remain accurate; the regression is in short-baseline
relative-pose precision (high-frequency pose jitter), which is exactly what multi-view
geometry depends on.

Environment

• ARCore / Google Play Services for AR runtime: 1.54 (260890093). Default client behavior
  also reproduces on the runtime that ships as the default min_apk floor (1.47 / 242590000).
• Devices (reproduced on both): Pixel 9 (Android 16) and Samsung Galaxy S26.
• ARCore client SDK: com.google.ar:core:1.47.0.
• Not affected: iOS / ARKit on the same physical scenes (co-captured, rigidly mounted).

Expected vs actual

• Expected: relative camera pose between nearby frames is precise enough that matched
  image features triangulate consistently (as in older ARCore / ARKit).
• Actual (on the regressed VIO): short-baseline relative pose is imprecise — matched
  features fail to triangulate consistently (points land behind the camera / at absurd
  depths), and high-frequency jitter appears in low-amplitude pose axes. Any multi-view
  consumer (MVS depth, photogrammetry, SLAM refinement) degrades badly.

The key signal: min_apk_version flips the behavior on one runtime

We swept com.google.ar.core.min_apk_version (manifest meta-data, tools:replace) with the
same installed runtime (1.54) and measured the downstream multi-view depth model's
confidence (a proxy for relative-pose consistency; fraction of frames usable):

min_apk_version	≈ ARCore version	tracking quality
26	pre-1.0	good (but camera_config_manager FatalException on Pixel 9)
120000000	~1.20	good
180000000	~1.40	good
210000000	~1.44	regressed
242590000 (client default)	1.47	regressed

The flip is sharp: good through ~1.40, regressed by ~1.44, and it persists through the 1.54
runtime. Because only the declared compatibility level changes (not the runtime), this is an
ARCore-side, compat-gated VIO change.

Steps to reproduce

1. Minimal ARCore app, default config (or high-res camera config), Session + Frame
   motion tracking; log frame.camera.getPose() per frame.
2. Build/run with com.google.ar.core.min_apk_version = 242590000 (or no override → default).
   Hand-scan a textured scene with lateral motion.
3. Rebuild with min_apk_version = 180000000. Repeat the same scan.
4. Compare short-baseline relative-pose precision between the two (e.g., feature-match two
   nearby frames, triangulate with the ARCore relative pose, check reprojection error /
   cheirality; or feed both pose streams to any multi-view depth/SfM step).
   • 242590000: high reprojection error, points behind camera, jittery low-amplitude axes.
   • 180000000: consistent triangulation, smooth poses.

Impact

Breaks multi-view depth (real-time mesh) on current ARCore. Only workaround today
is pinning min_apk_version to ~1.40 (180000000) — which is fragile (can't go below ~1.0
without the camera_config_manager crash on some devices, and blocks adopting newer ARCore).

Ask

• Confirm what changed in the VIO/tracking pipeline between ~1.40 and ~1.44 that degraded
  relative-pose precision, and why it is gated by the declared min_apk_version.
• Restore the older precision on the modern pipeline (or expose a supported way to select it)
  so apps can target current ARCore without the regression.

Attachments (available on request)

• Per-frame pose tracks (ARCore vs ARKit, co-captured) showing matched global trajectory but
  excess high-frequency jitter on the regressed VIO.
• The min_apk_version sweep captures + confidence measurements.