Termux
ADB

This was just a quick utility I needed to build to solve a very specific, and frankly, annoying personal problem. I wanted to get a specific set of transactional data out of my banking app and pipe it into another self-hosted finance dashboard. The banking app, as expected, is locked down tighter than a drum—no easy exports, and certainly no APIs. I wasn't after files or logs; I needed the actual visual text data from the screen.

My approach was simple: leverage Termux on the Android device itself to run ADB and scrape the screen's DOM-like XML structure using uiautomator dump. This seemed like the perfect Pragmatic Utility Build—a self-contained tool that could run periodically.

II. The Solution (Implementation)

I started by installing the necessary binary tools right in the Termux environment:

Bash

pkg install android-tools

Once ADB was available, the goal was to achieve a fully automated, self-connecting setup. Termux and ADB are technically capable of connecting back to the host device, but you need to enable Wireless Debugging in the Android developer settings. This is where the whole thing comes crashing down—the intended security feature prevents my automation.

The Automation Roadblock: Dynamic Ports

The core technical issue is that while you can pair once, the actual connection port for Wi-Fi ADB is dynamic every time you restart debugging. This is a security feature, and it's robust.

  • Step 1: Initial Pairing. This is the first hurdle. You must enable Wireless Debugging and grab the temporary pairing code and port. Because the Termux app cannot be left, I had to SSH into Termux to run the pairing command while the screen was active:
adb pair <ipadress>:<pairing port> <pairing code>
  • Step 2: The Manual Connection Barrier. After pairing, the actual connection port changes. The only way to find it is to manually look in the Android settings screen every single time, find the new port (e.g., 192.168.1.100:43219), and then run the connect command.
adb connect <ipadress>:<dynamic port>

Because this port changes—and there's no non-root, programmatic way to surface the current port value from the host device's settings into Termux—the whole concept of an unattended, periodic scrape is dead. It's a classic case where security trumps convenience, and I totally get why it's designed this way—it'd be wayyyyy too much of a security risk otherwise.

The Pragmatic Pivot: Cable Scrape

The goal was data extraction, not wireless purity. The most reliable and fastest solution, which bypasses the dynamic port problem entirely, is using a physical connection.

My final implementation: I abandoned the Wi-Fi ADB attempt entirely and defaulted to running my scripts from an external device (my desktop) connected via a USB cable. This connection is stable, doesn't require pairing, and is persistent. It's a less elegant solution, but it works.

The scraping script focuses on getting the view hierarchy when the banking app is open:

  1. Dump the XML of the currently active view into the phone's temporary storage.
  2. Pull that XML file to the local execution environment (the desktop).

III. The Code Showcase

The most critical part of this utility is the precise sequence of ADB commands needed to grab the screen's layout—the UI Automator dump. It's the technical heart of the process.

Bash

./bin/darwin/adb shell uiautomator dump /sdcard/window_dump.xml \
&& ./bin/darwin/adb pull /sdcard/window_dump.xml tmp.xml

This single line dumps the active UI into an XML file (window_dump.xml) on the device's storage and then immediately pulls it to the local machine (tmp.xml) for further parsing. The whole process relies on that uiautomator utility and the active shell command chaining.

IV. Wrap-up & Links

While the pure Termux-to-host automation was a bust, the actual data scraping is now robust and fast, using the physical USB cable as the reliable connection mechanism. The next step is parsing that XML structure to find the specific XPaths for the transactional data I need.

View the full XML parsing script here on github (once I write it).

Check out the final finance dashboard where the data lands here (WIP).

Would you like me to draft a follow-up post on the XML parsing of the uiautomator dump file, focusing on finding the XPath for the transaction text?