Runtime Options

Choose a runtime without tool shopping

A Kotlin Android dApp needs Android to exercise its native behavior. The available paths include a physical test device, an Android Studio emulator, a hosted Android emulator and a cloud real-device session. Each is useful for a different observation. The right choice is the one that can run the required action with honest labels, not the one with the longest repository list or most impressive marketing.

Match the runtime to the gate

For launch and navigation, a hosted emulator is sufficient to produce an environment-specific observation. For Mobile Wallet Adapter, the runtime must provide a compatible wallet association path and allow the user's approvals. For hardware-backed key behavior, thermal characteristics or battery performance, a physical device provides evidence an emulator cannot. Cloud real hardware should be labelled cloud real-device session; it is hardware evidence with a hosted operational boundary.

Local emulators commonly depend on host virtualization and graphics configuration. Dockerizing the Android emulator does not magically remove those dependencies. If KVM is unavailable or crashing, a container using the same acceleration path may fail for the same reason. Software emulation can be attempted where supported, but boot time and usability depend on the machine and image; no fixed success promise belongs in the runbook.

Keep boot attempts bounded

List the available AVDs, check emulator acceleration and start a known image with a graphics mode supported by your installed emulator version. Old flags may be deprecated, so read the local tool's help rather than copying a command indefinitely. Capture diagnostics and impose a time limit. If a first boot fails, distinguish a graphics problem, image problem, insufficient disk space and virtualization failure before changing multiple variables.

A data wipe is destructive to that emulator's state. Do not use it casually after a wallet or receipt has been configured. A fresh named AVD preserves an existing test environment and makes the new attempt easier to identify. If no runtime can complete the wallet flow within the testing budget, preserve the attempted result and use a correctly labelled interface walkthrough rather than fabricating a transaction.

Plan the wallet environment

A Play Store image can simplify wallet installation, but it brings account sign-in and network requirements. A non-Play image needs an official distribution channel for the chosen wallet. Do not download wallet APKs from unknown mirrors or import a production seed into a test environment. The official mock wallet is another development option, with its own authentication requirements and limitations.

The hosted Appetize environment used for EdgeORE has demonstrated launch and navigation. Later sessions reached an authorization sheet but did not establish a completed connection in the earlier attempt. That is useful diagnostic context, not proof that every hosted session can or cannot support wallet apps. Record the specific session setup and wallet build instead of turning one attempt into a permanent platform claim.

Decide and continue

Spend a bounded period diagnosing a failing runtime, then choose a supported alternative or an honest partial qualification. The next useful artifact is a launch log, an authorization result or a recorded error. Another unrelated wallet repository does not close any of those gates. A runtime decision is complete when the test environment is documented and the next action has measurable acceptance criteria.

---

Wiki home · Qualification updates · Sources and credits