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 standalone Android integrity collector inspects already-loaded class names without initializing third-party code, mapped libraries and stack frames, process thread names, and known injector pipe targets. It does not open sockets. The separate Frida scan, now owned by the optional active-probes component, connects to localhost and reports port-open and handshake-prefix booleans. It currently collapses connection errors into false and handshake errors into a false reject flag; it does not expose separate native timeout or unavailable outcomes. A REJECT-like reply is protocol evidence, not proof of a service's identity.
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.