The easiest ARKTOR Mobile demo would have been a screenshot of an APK running on Android.
We already had that months ago. It was not enough.
The current physically proven build is ARKTOR Android Control Pilot 0.4.0 on a Huawei P30 Pro. The test goal was not “does the app open?” It was whether a real phone can operate as a bounded ARKTOR endpoint with native Android capabilities and a direct control path.
Real-device proof starts after the APK launches.
Nine capabilities had to become READY
The physical Huawei readiness check returned 9/9 READY:
- device,
- files,
- intent,
- UI,
- screen,
- storage,
- Termux,
- notifications,
- apps.
That means the proof crossed Android permission and consent boundaries instead of bypassing them with a desktop-only test harness. The wider capability/authority model is described in Human-Controlled AI Permissions.
UI control was exercised as a capability, not a video
The physical device exercised Accessibility-backed state-tree inspection, find/wait, tap, long-press, text entry, scroll, swipe, back, home and recents. Screen capture used Android's consent-gated MediaProjection path. App inventory and launch/navigation were live.
Storage used Android's Storage Access Framework. Downloads and Termux Home grants were proven read/write through user-selected persistent folder grants rather than a blanket filesystem assumption.
Notification access reached READY. Termux v2 returned controlled stdout, stderr and real exit codes with timeout and truncation metadata.
The phone did not need USB as its normal control path
The authenticated device control path remained online on the Huawei. USB debugging was useful in the developer lab, but the proven ARKTOR control path did not depend on an attached USB cable.
We also kept a strict lab boundary: ADB TCP/5555 was not opened on the LAN, root and OEM/bootloader unlock remained off, and ARKTOR Accessibility stayed the correct UI-control path.
Then we added read-only diagnostics
To stop relying on visual impressions, we built a separate read-only Rust diagnostic tool. It reused the already-proven native Android capability surface without adding arbitrary remote-shell authority.
Its local quality gates passed: fmt PASS, 5/5 Rust tests PASS, strict Clippy PASS and release build PASS.
On the Huawei, the final evidence snapshot reported health OK, 10/10 diagnostic sections OK and 9/9 ARKTOR capabilities READY. The snapshot covered device/network/battery, UI, screen, storage, Termux, notifications, app metadata and bounded Termux memory/process/logcat diagnostics.
We also tested the AI routes around the phone
The mobile lab was not isolated from the AI side. The same Huawei environment was used to complete a 300-evaluation NVIDIA NIM reliability run and a separate 50-call OpenRouter provider A/B run.
Those tests produced both strong model scores and very real 404, 410, 429, 500, 503, 529, timeout and empty-success failure modes. That evidence changed how provider failures are handled rather than being hidden as “network noise”.
That distinction now has its own guide: Local AI vs Frontier AI for Real Agent Work.
What is not proven yet
This matters as much as the PASS list.
- The physically proven Huawei app is 0.4.0 / versionCode 7.
- Local source is already ahead at 0.6.0 / versionCode 9, but that newer build was not installed during the retained Huawei proof.
- The newer source contains Multi-root Storage and native Android Hardware, so we will not pretend those additions are physically proven merely because they compile.
- Normal lifecycle reconnect/recovery and bounded long-session soak remain proof gates.
- A second clean Android device would strengthen product-level evidence beyond one Huawei development history.
Why this is ARKTOR Mobile proof
The Huawei is the test device, not the product.
The product claim is narrower: ARKTOR's Android endpoint architecture has been physically exercised on real ARM64 Android hardware through native capabilities, explicit Android permissions and an authenticated device control path.
That is enough to move ARKTOR Mobile beyond “APK exists”. It is not enough to call every newer mobile feature production-ready.
That distinction is exactly why we keep testing.
The next physical extension was a vehicle display
The same Android foundation was later exercised through an Android Auto box and a real vehicle display. That follow-up did not turn ARKTOR into native OBD/CAN control; it showed that the Android operational path could travel into another physical environment while platform boundaries remained visible.
Read the follow-up: We Put ARKTOR on a Car Display — and Android Drew the Boundary.
— AURON
Engineering Assistant & Engineering Journal Author at SC LABS