On this page
Runtime evidence
See emulator and instrumentation clues separately
A useful event says which build marker, file, property, thread, class, library, pipe, or port was observed. It does not compress those values into an unexplained boolean.
Use independent observation layers
| Layer | Examples | Why preserve it |
|---|---|---|
| Build and hardware | Build fingerprint, model, ABI, QEMU properties, virtual CPU markers | Explains why an environment resembled an emulator. |
| Filesystem and packages | Known emulator files and installed emulator-related packages | Supports family-specific analysis without a global verdict. |
| Runtime | Debugger state, hook classes, stack frames, mapped libraries, threads | Captures instrumentation that build metadata may not reveal. |
| Local endpoints | Frida handshake, reverse-engineering ports, injector pipes | Provides transaction-time evidence with explicit failure states. |
Emulator and simulator observations
Android checks can return the matching build fingerprint, virtual hardware properties, CPU and vendor markers, sensor counts, camera availability, emulator file paths, related packages, and which checks actually ran. Recognized families can include AOSP or Google emulators, Genymotion, BlueStacks, Nox, MuMu, LDPlayer, MEmu, and others represented in the published catalog.
iOS reports simulator build and environment markers when available. Development simulators are legitimate tools, so emulator evidence needs action context rather than automatic blocking.
Frida and hook observations
The integrity probes can inspect already-loaded class names without initializing third-party code, parse mapped libraries and stack frames, inspect process thread names, observe known injector pipe targets, and test selected loopback ports. A separate Frida scan can perform a constrained local handshake and preserve connect, timeout, protocol-reject, and unavailable outcomes.
Collect at the right moment
Long-lived startup values and action-time runtime values answer different questions. Collect a baseline after app initialization, then collect a narrow transaction profile near confirmation of a payment, recovery, or protected account change. Bind both events to the same server-created action while giving each upload its own idempotency key.
See the protected actions and payments guides for complete flows.
Calibrate before policy
- Test release builds on supported physical devices and OS versions.
- Keep emulator and simulator samples as separate development cohorts.
- Measure probe latency, timeout rate, missingness, and value distributions.
- Review vendor-modified Android builds and managed enterprise devices.
- Never block from one observation and provide a recovery path for policy decisions.
The SDK does not calculate a risk score or return a trusted or untrusted verdict.