Run the app. Watch what it really does.
Static analysis tells you what a build is capable of. Dynamic analysis shows what it does when it executes. Mobexa launches your app on an instrumented Android device, drives it, and records the hosts it reaches, the data it writes, the secrets it leaks at runtime and the defenses it actually enforces - not the ones it claims to.
The runtime behaviours that decide whether an app is safe to ship
A build can pass every static rule and still betray its users the moment it runs. Dynamic analysis watches the parts of the story that only exist in execution.
Network egress
Every host the app reaches, the protocol it uses, and whether sensitive data leaves over an encrypted channel or in the clear.
TLS & pinning
Whether transport security is genuinely enforced or quietly bypassed - the gap between a pinning library being present and pinning actually holding.
Storage & logs
What the app writes to disk, cache and system logs at runtime - the favourite resting place for tokens that should never be persisted.
IPC & components
How exported components respond when something other than your own UI talks to them - the surface that drive-by apps probe first.
Runtime secrets
Credentials and tokens that never appear in the binary because they are assembled or fetched only while the app is live.
Enforced defenses
Root and emulator detection, anti-tamper and integrity checks tested for whether they actually trigger, not just whether they exist.
Two views of the same app, reconciled into one backlog
A static finding says a weakness is possible. A dynamic finding says it happened. Together they remove the two arguments that stall every mobile security review - "that code path is never reached" and "we handle that at runtime." Mobexa runs both and reconciles them, so your team debates fixes instead of debating whether a finding is real.
- Confirmed at runtime findings carry captured evidence - the request, the write, the log line.
- One severity model and one MASVS mapping across static and dynamic results.
- Reproducible runs on a reset environment, so a result is not an accident of device state.
# captured while the app was driven on device [net] GET https://api.example/v2/profile TLS1.3 pinned ok [net] POST http://t.analytics.example/e CLEARTEXT body: device_id, session_token [fs ] write /data/cache/auth.json contains bearer [def] root-detection enforced [def] tls-pinning bypass attempt SUCCEEDED # -> 2 findings raised, mapped to MASVS-NETWORK-1
Dynamic analysis, answered plainly
What does dynamic analysis catch that static analysis misses?
Behaviour. Static analysis sees that an app contains a networking call; dynamic analysis sees which host it actually reaches, whether the channel is encrypted, whether certificate pinning is enforced and what data crosses the wire. Logic that only assembles at runtime - keys fetched from a server, endpoints built from config - is visible only while the app is executing.
What environment does the app run in?
Each build runs on an isolated, instrumented Android emulator that Mobexa controls, available on both x86_64 and ARM64 so ARM-only native libraries execute instead of being skipped. The environment is reset between runs, network egress is observed, and storage, logs and inter-process traffic are captured. There is no shared state between one customer's run and another's.
Do you support iOS dynamic analysis?
Android dynamic analysis is the deepest, because the platform allows full device instrumentation. iOS dynamic coverage is more constrained by the platform itself; where the OS limits observation, Mobexa is explicit about it rather than implying coverage it does not have.
Can dynamic results feed the same triage workflow as static findings?
Yes. A runtime finding - a cleartext request, an unpinned TLS session, a secret written to logs - lands in the same triage queue with the same severity model, MASVS mapping and evidence record as a static finding, so one team works one backlog.
See the traffic and the writes your build produces in the wild.
Give us a build and a short user journey. We will return captured runtime evidence and the findings it raises.