Hi @krono — thanks for improving the Android interface.

I tested the change, but it did not work on my research device (rooted via Magisk). I’m hitting the following timeout during the root check:

in _check_timeout
    raise TimeoutExpired(
    ...<2 lines>...
            stderr=b''.join(stderr_seq) if stderr_seq else None)
subprocess.TimeoutExpired: Command '['adb', 'shell', 'su 0 "id -u"']' timed out after 5 second

From what I can tell, the issue originates in ADB.find(): it currently only catches ValueError, but detect() can also raise subprocess.TimeoutExpired when a command exceeds the timeout.

On a MagiskSU device, when SuADB runs su 0 "id -u", su prints the help text and then either blocks waiting for input or eventually times out. Since TimeoutExpired is not handled, the exception bubbles up and the process aborts instead of falling back to the next ADB implementation.

Thanks for the improvement — much appreciated :-)
I’m happy to help iterate—if you add timeout handling for MagiskSU detection, I can quickly retest and confirm it behaves correctly across rooted and non-rooted devices.

All the best

Daniel

Thanks for the Feedback.
My bad not testing thoroughly.
I was focused on the test suite and on getting the "su-less" case working. Will add timeout instantaneously.

note: i did not touch the "Stand alone" files… so if there's some syncing to do…

The standalone version is actually a relict from the past and right now we don't have any intention in updating that. At least for now.

Regarding your last changes: The issue of adb is now gone but no tpcdump capture is done - at least on my device:
[-] error pulling pcap (/data/local/tmp/_mobilepcap2.pcap) from android device

In my case no pcap was created and I saw no tcpdump process running on my device. Maybe you can add at first some debug output of the actual command being invoked when we are trying to run tcpdump?

The command I used was the following:

fritap -m -p mobilepcap2.pcap -f -k test.log -do -v Chrome

Makes sense. For my local debugging (where I found out the tcpdump syntax was broken due to multiple quoting), I insturmented all of that. shall this be done on -d only or also on -do?

On a related note, the android.py module does not use the global (let alone the "special") logger; I would have done that but the PR is messy enough already

Makes sense. For my local debugging (where I found out the tcpdump syntax was broken due to multiple quoting), I insturmented all of that. shall this be done on -d only or also on -do?

On a related note, the android.py module does not use the global (let alone the "special") logger; I would have done that but the PR is messy enough already

You’re absolutely right — the PR is already a bit messy, and I really appreciate the work and the effort you’ve put into improving the Android interface.

Regarding your question: I’d enable the instrumentation for both -d and -do. In most cases, the regular debug output -do (without starting Frida in debug mode) is already sufficient, so having it available in both modes is helpful.