Android Implementation

[tristanheilman]

Need to start gathering documentation to get an idea of how this package can implemented for React Native - Android. If you see this and have insight, please review any previous discussion log and contribute!

[tristanheilman]

Looks like there is ARCore which provides some documentation that may be useful. This specific link looks interesting: https://developers.google.com/ar/develop/java/camera-sharing#overview_of_enabling_an_app_to_share_camera_access_with_arcore

[tristanheilman]

Research update — August 2026

Picking this thread back up and doing the full survey. Everything below was verified against
primary sources on 13 August 2026; vendor pricing and API shapes move, so re-verify before
anyone commits code or money to any of it.

The camera-sharing lead was the right instinct

Shared camera access turns out to
be the single most useful ARCore primitive for this problem, for a reason that isn't obvious from
the page title. It lets an app "switch seamlessly between exclusive control of the camera via the
Android Camera2 API and sharing camera access with ARCore" — so you can hold ARCore's motion
tracking while pulling full-resolution stills through Camera2.

That gives you high-res JPEGs with a known 6-DoF pose attached to each one, which is exactly what a
photogrammetry pipeline wants, and is the only realistic route to recovering metric scale on
Android. Scale is otherwise the hardest gap — this library exposes onDimensions in metres from
Apple's .bounds, and a photogrammetry pipeline fed loose JPEGs reconstructs up to an unknown
scale factor.

Caveats, and they're device-tier dependent:

• ARCore already takes two streams by default (1× YUV CPU for motion tracking, 1× GPU). Your
  capture surface is on top of that.
• Google's stated budget for high-end phones is "2x YUV CPU streams, 1x GPU stream, 1x
  occasional high res still image (JPEG), e.g. 12MP". Mid-tier phones support fewer simultaneous
  streams — a concurrent high-res still may not be available at all.
• "Requesting additional custom surfaces increases the performance demands of the device."

Note "occasional" in Google's own wording. This supports a deliberate capture cadence — a frame
every so often as the user orbits the object — not a continuous high-res burst.

The gap this doesn't close

Apple's Object Capture is two products behind one API: a guided capture UI (where to move next,
have you covered enough of the object) and an on-device reconstruction engine (images → scaled
USDZ). Camera sharing helps with the first half. Android has no API for the second half at any
level, from Google or the OEMs.

Confirmed against current ARCore docs: no mesh reconstruction, no scene meshing, no object
scanning, no model export. The feature request for a RoomPlan-style API
is still open and unanswered. ARKit's ARMeshAnchor has no counterpart.

Three findings that shaped the conclusion

1. Hardware isn't coming back. Every Android phone that Google's
supported-devices list flags as having a hardware depth
sensor is a 2019 or 2020 model — Galaxy S10 5G, Note10+, A80, S20+/S20 Ultra, LG V60. LG left the
phone business in 2021; Samsung hasn't shipped ToF since the S20 generation. There is no Android
tier to target the way this library targets iPhone 12 Pro and later. Google's answer is software
depth-from-motion at "over 88% of active devices" (May 2026) — the opposite bet from Apple's, and
it means an Android implementation works from RGB plus estimated depth on a wide, unpredictable
device population.

2. Google's AR investment moved to headsets and glasses.
ARCore for Jetpack XR hit
1.0.0-beta02 on 12 August 2026 with depth maps, hand/eye tracking, anchors, plane detection and
AugmentedObject — which is object tracking (recognising configured categories), not object
capture. A whole new perception API generation shipped to beta with still no reconstruction.

Meanwhile the classic phone SDK is maintained but static: v1.54.0 (Apr 2026), v1.53.0 (Mar 2026),
v1.52.0 (Dec 2025) — steady releases, no new capability in this area.

The part worth flagging for anyone considering Android work here:
running Jetpack XR on phones
is already in developer preview, and reaching the classic ARCore Session/Frame from it requires
opting into UnsupportedArCoreCompatApi, which is "exposed for compatibility reasons, and will be
removed in a future release." So anything built against com.google.ar:core today has a migration
ahead of it. That's a dated cost, not a hypothetical one.

3. Every working Android product routes through a server. The survey of what exists:

Option	Runs	Object-level	Usable as a dependency
KIRI Engine REST API	Cloud	✅	✅ self-serve, ~$1/scan, 20–300 images, exports USDZ
Luma AI	Cloud	✅ splats	⚠️ enterprise / contact sales
Polycam	Cloud	✅	❌ not self-serve
Niantic NSDK 4.0	On-device + cloud	❌ spaces, not objects	⚠️ partner program
Epic RealityScan Mobile	On-device	✅	❌ app only, no SDK
COLMAP + OpenMVS	Your GPU server	✅	✅ but you operate it

Nothing both runs on device and reconstructs objects as a linkable Android dependency. KIRI is
the most accessible integration target and notably can emit USDZ, so one backend could in principle
feed both platforms.

One genuine parity win worth recording: Scene Viewer
is a real QuickLookView analogue (no deprecation notice on it) — but glTF/GLB only, HTTPS-hosted
only, no local files, and a 10 MB / ~100k triangle cap. A model reconstructed on device can't be
displayed without uploading it somewhere first.

Where that leaves the recommendation

Roughly a third of the current API surface maps cleanly to Android, a third needs reinvention
(Apple's scan-pass coverage model is proprietary and reproducing it is a research problem, not an
integration), and a third can't be done on device at all.

The decisive argument isn't difficulty, it's what this library is. Its value is being a thin,
faithful wrapper around a framework Apple maintains — users get Apple's capture quality, and the
maintenance job is bridging. Android inverts that: there's no framework to wrap, so the guidance
model would be original CV work and reconstruction would be a vendor bill. Shipping something
called Object Capture on Android that produced visibly worse results, cost money per scan, uploaded
users' photos and couldn't report real-world dimensions would hurt the library more than the
missing platform does.

So: no native Android parity for now. "iOS-only, because Apple ships something Android doesn't"
is a defensible position that costs nothing to hold and stays true until Google changes it.

If it's ever revisited, the ordering should be:

1. A pluggable reconstruction backend — a platform-agnostic JS interface so an app supplies
   KIRI, Luma or its own server. Needs no Android native code, and earns its keep on iOS
   immediately (detail levels beyond reduced, off-device processing for older hardware).
2. Then capture-only on Android — the ARCore + shared-camera session above, emitting
   pose-tagged images for that backend to consume.

Not a bespoke Android reimplementation of the whole surface. A backend earns value on day one; a
rewrite earns nothing until it's finished.

Triggers to revisit

Rather than a date, specific events worth watching (cheapest check: re-read the ARCore and Jetpack
XR release notes after each Google I/O):

1. Google ships a reconstruction or scene-meshing API in ARCore or Jetpack XR — the direct unblock.
2. A vendor ships a real on-device Android object-reconstruction SDK with public licensing.
   Niantic is closest, but their focus is spaces.
3. An OEM reintroduces a depth-sensor tier with meaningful share. No signal.
4. Android XR handset convergence completes and picks up meshing along the way.

Write-up

Now on main in docs/android/, with sources for everything above:

• Current state — what the package ships on Android and how each API degrades
• Platform capabilities — ARCore, shared camera access, depth, hardware, viewers
• Third-party options — cloud APIs, SDKs, self-hosted pipelines
• Roadmap signals — where Google is heading, and the triggers to revisit
• Recommendation — the call, per-API parity analysis, alternatives considered

The audit also cleaned up what was there (#25). Both Android view managers were unreachable dead code — every view component returns null off iOS before reaching the native component — and RNObjectCaptureModule held a name and nothing else, so all three are gone. Android is now one module with three methods that reject with NOT_IMPLEMENTED, which keeps the build green and names the reason.

Two things worth knowing if you depend on this on Android:

• ObjectCaptureSession.isDeviceSupported() is the capability gate. It now resolves false
  instead of rejecting when the native module is absent, so prefer it over branching on
  Platform.OS — plenty of iOS devices lack LiDAR too.
• Importing the package on Android no longer risks throwing. ObjectCaptureConstants was
  reading .constants off a module that is undefined there once the empty stub was removed;
  it's guarded now. It was already undefined on both platforms, so nothing of value was lost.

Contributions and corrections welcome, especially from anyone who has shipped ARCore capture in
production — the device-tier limits on shared camera streams are the part I'd most like real-world
data on.