How to Use frida-trace to Log Android App Calls Without Writing a Script

TL;DR: frida-trace logs function calls and their arguments without requiring you to write a hook script first. Give it include patterns like -i "open*" or -j "com.example.app!*", attach or spawn the app, and it generates editable handler files under __handlers__/ that you refine as you narrow down what you are looking for.

When you open an unfamiliar Android app with Frida, the usual first step is writing a script — but you don’t always know which methods to hook yet. frida-trace, which ships with the frida-tools package, solves that: it auto-generates hooks for every function matching your patterns and logs call arguments, so you can explore a live app and only then write the targeted script. This guide covers the patterns and flags that make it useful for Android analysis. All commands and options below come from the official frida-trace documentation.

Prerequisites

You need a working Frida connection to the device: frida-server running as root, or the target app repackaged with Frida Gadget (see How to Run Frida on a Non-Rooted Android Phone with Frida Gadget). Verify with frida-ps -U — it should list the device’s processes. frida-trace itself needs no script; the tool generates them for you.

Tracing native functions

The -i flag includes exported functions by name pattern. Attach to a running app by process name with -n:

frida-trace -U -n com.example.app -i "open*" -i "read" -i "write"

This logs every call to functions whose names start with open, plus read and write — a quick way to see which files an app touches on launch. To trace inside one library only, use -I with a module pattern:

frida-trace -U -n com.example.app -I "libnativelib.so"

Two more include flavors are worth knowing: -a traces an unexported function by address (-a "libjpeg.so!0x4793c"), and -s matches debug symbols. Use -x to exclude noise, e.g. -x "libc.so!*" to drop libc chatter while tracing everything else.

Tracing Java methods

On Android, -j includes Java methods by pattern. The syntax is CLASS!METHOD, and it supports wildcards:

frida-trace -U -n com.example.app -j "com.example.app.MainActivity!*"

This logs every method call on MainActivity. The official docs use modifier flags after a slash to refine the match: i ignores case, s matches by signature, and u limits matching to user-defined classes, skipping framework code. Their example traces Java methods with “certificate” in the signature, case-insensitively, in user classes only:

frida-trace -U -f com.google.android.youtube --runtime=v8 -j '*!*certificate*/isu'

Note the -f flag here instead of -n: it spawns the app fresh and attaches at launch, which is what you want when the interesting calls happen during startup — for example, a license or integrity check that runs before you could attach manually. A single constructor call can be traced with -j "com.example.app.MainActivity.$init".

The flags that matter

Refining the generated handlers

For each matched function, frida-trace writes a handler file under a __handlers__/ directory. Each handler exposes onEnter (log or inspect arguments) and onLeave (log or modify the return value). The tool picks up edits to these files live — you refine the handler while the app keeps running, turning a generic trace into a targeted hook without restarting. This is the workflow the tool is built for: start wide, then edit handlers down to the calls that matter.

A practical recipe: mapping an app’s crypto calls

A common first pass on an unknown app is finding where it does cryptography. Combine a module include with a name pattern, spawn the app fresh, and watch:

frida-trace -U -f com.example.app -I "libcrypto*" -i "*encrypt*" -i "*decrypt*" -i "*digest*"

The __handlers__/ files will show you which functions fire and with what arguments. From there, edit the onEnter of the interesting handler to dump buffers, or switch to a hand-written script once you know the exact method — the patterns from the Java.use hooking guide pick up where tracing leaves off.

When frida-trace is the wrong tool

Three honest limits. First, tracing everything in a large module is slow and floods the log — start narrow or you will drown in output. Second, it only sees what you pattern-match; heavily obfuscated native code with mangled names needs a disassembler first to find anchor points for -a address traces. Third, it cannot see inside interpreted code or calls that never cross a hooked boundary, so a trace that shows nothing does not prove nothing happens.

Key takeaways

• Use frida-trace for exploration: it generates hooks from patterns like -i "open*" and -j "com.example.app!*" so you learn before you write a script.
• Spawn with -f to catch startup behavior; attach with -n to a running app.
• Refine the auto-generated handlers under __handlers__/ live — edits apply without restarting.
• Start narrow: broad traces on big modules produce unusable log floods.

References

• frida-trace — Frida official documentation (all command examples and flag behavior)
• How to Hook Android App Methods with Frida: Java.use, Overloads, and Native Hooks
• How to Run Frida on a Non-Rooted Android Phone with Frida Gadget