An APK installing on Android does not prove that its full workflow will work on a virtual phone. Separate installation compatibility, visible UI control, external service requirements and hardware-dependent behavior. That gives you a failure you can diagnose instead of a broad “the agent cannot use this app” verdict.
Mobilebox’s current runtime is Android 14 on arm64. It is a virtual Android sandbox, not a physical handset or an iOS device. Evaluate the specific build and task you own before treating a successful Settings demo as proof about a third-party application.
Check the build before the agent
Use an arm64-compatible APK or the appropriate split bundle. Keep the package name, version and signing identity associated with the test. Uploading a web landing page in place of APK bytes, selecting the wrong CPU build, or installing an incompatible update can fail before UI automation becomes relevant.
The installation guide covers local bytes, direct URLs and split selection. After installation, use the returned package name for open_app. The app’s marketing name is not necessarily its package identifier.
curl --fail-with-body "$MSB/v1/phones/$ID/apps" \
-H "Authorization: Bearer $MOBILESANDBOX_API_KEY"
curl --fail-with-body "$MSB/v1/phones/$ID/device" \
-H "Authorization: Bearer $MOBILESANDBOX_API_KEY"These requests establish installed packages and the device information exposed by the API. They do not establish that a specific payment, biometric or location-dependent operation is supported.
Identify what the task depends on
Android apps can declare required hardware and software features in their manifests. Android’s manifest documentation explains that those declarations participate in device compatibility and store filtering. Sideloading a package does not make absent physical functionality appear.
A useful preflight list includes the following distinctions:
| Dependency | Question to answer |
|---|---|
| Accessible UI | Does the required control expose text, an id or a usable description? |
| Custom rendering | Can a screenshot establish the state the tree omits? |
| Device services | Does this build require a particular platform service to launch or sign in? |
| Hardware | Does the actual task need a camera, NFC, biometric sensor or another physical feature? |
| Remote account | Is the account authorized, usable in staging and allowed for this workflow? |
| Attestation | Does the application accept this execution environment? |
Do not confuse attestation with a targeting error
Google’s Play Integrity overview describes verdicts about app authenticity, installation and device integrity, including signals relevant to emulated environments. An app that rejects its environment has reached a different boundary from an app whose Save button is hard to locate.
Mobilebox does not promise that every Play-protected, DRM-protected or hardware-dependent application will work. Do not turn a failed environment check into an undocumented bypass claim. Record the app-visible failure and evaluate an authorized test build or appropriate device environment instead.
Use a staged compatibility probe
First prove service access with the quickstart. Then install the exact app, open it, observe the foreground package and capture the first meaningful screen. Next test one harmless operation, verify its result, and finally check any persistence requirement.
For scale, one recorded run on October 30, 2026 took five account-free F-Droid builds through that sequence on this runtime. Each completed its task once, kept the result through an app restart and through park and resume. The builds were Fossify Notes (versionCode 13), Fossify Calculator (10), Catima (1006), Loop Habit Tracker (20302) and Fossify File Manager (14). That is evidence about those builds and those steps. It does not cover other apps, newer versions, Google Play apps or physical handsets.
Classify the first failure at its actual layer. “APK architecture mismatch”, “permission not granted”, “blank protected capture”, “remote sign-in refused” and “stale target” imply different next steps. Reinstalling or tapping again without that distinction can erase useful state or repeat side effects. The error guide and retry guide provide the recovery contract for the supported API surface.