python scripts running on adb + usb hub question

G

gooroo

Newbie
Joined
May 10, 2026
Messages
11
Reaction score
1
Hi, i do not know if this is the right thread, sorry if it is not but i do not know where to post this. I have a little issue on which i need some help figuring out.

I am running python scripts via ADB on different samsung devices, light scripts, 250lines per script max, they mostly do: switch between apps, change settings, click some things, etc, in an infinite loop. These phones are connected on proxies, so i cannot use wireless debugging as far as i know, only USB debugging (for adb connection)

What i want to do basically: get some kind of usb hub, plug it into a wall outlet, so the hub gets power, plug it in a USB 3.0 port in my PC, and connect all the phones to the hub, so they have stable power supply from the wall outlet, and stable connection to ADB, using only 1 PC port. Asked chatbots but i get vague answers and do not know if this thing is stable

PC specs: r7 9700x, msi b650-a wifi, msi psu 850w, rtx 5070, 32gb ram ddr5 6000mt, many USB 3.0 ports but i'd rather get a hub and keep everything clean and tidy.

Would there be an issue with transfer speeds, power cutoffs, scripts breaking, adb failing, etc? What hubs would yall recommend? Is my idea good, or are there better alternatives? Any idea/suggestion would be highly appreciated, thank you ❤️
 
Advertise on BHW
Fenixn0 said:
Hey man, welcome to the automation side. Your PC specs are a beast, so hardware bottlenecks on the PC side won't be an issue at all.
However, building physical Android farms brings specific challenges. Here is a breakdown of your issues and how to solve them:
1. The Proxy vs. Wireless ADB Myth (You CAN do both)
You mentioned you can't use wireless ADB because of proxies. This is incorrect. Proxies route your external WAN (internet) traffic. ADB operates on your local LAN (192.168.x.x).
As long as your proxy app/software allows local network bypass (most apps like SuperProxy, Postern, or v2ray have a "Bypass LAN / Local Subnets" setting), you can keep the phones connected to the proxy AND control them via Wireless ADB simultaneously. This is often more stable than cheap USB hubs.
2. USB Hubs (Power vs. Data drops)
If you strictly want to use USB, you CANNOT buy a cheap generic hub. When running multiple ADB streams, the USB controller on your PC can easily get overwhelmed, causing ADB dropouts (devices going "offline"). Also, standard hubs don't provide enough amperage to keep phones charged while their screens are on running scripts.
Recommendation: You need an Active (Powered) Industrial USB Hub. Look for brands like Sipolar (industry standard for phone farms), Sabrent, or Orico. Make sure it has an external power brick (e.g., 12V/5A or more) and supports BC 1.2 fast charging on data ports.
3. Script Stability (The ADB bottleneck)
Even with the best hub, ADB over USB will drop connection eventually when running in infinite loops. Your Python script needs robust exception handling.
Do not just write a straight loop. Wrap your ADB commands in try/except blocks. If a subprocess returns an error (device not found), your script should automatically run:
os.system("adb kill-server")
os.system("adb start-server")
And then attempt to reconnect the device before continuing the loop.
Let me know if you need help structuring the Python exception handling for this. Good luck with the farm!
Click to expand...
Thank you so much for the info, proxies run on nekobox app and use socks5, wouldnt enabling LAN bypass have some kind of downsides? For example DNS leaks or whatever? Also, i basically let the scripts run on loop for about 12-24hours but i check on them every 2-3 hours or so, so even if one or two connections drop in this timeframe lets just say i can set them up again, i mean you are right, i would rather spare this hassle and would very much love for them to just run smoothly, also if you could explain a bit how this wireless debugging would work while the phones are on proxies in different countries with socks5, i would very much appreciate. Nonetheless, thank you for the extended education <3 here to learn and pass it down myself in the future :D

Every question or things i need clarifying were already run into chatbots but info is too vague and i just cant afford to just buy stupid things or do some steps wrong (time-wise i mean) i need a solid solution so i will execute it and make things work in 1try.
 
Fenixn0 said:
Glad to help! Your concern about DNS leaks is actually very smart and shows you are treating OpSec seriously. This is exactly why generic chatbots fail — they don't understand real-world routing.
Let me explain exactly how this works under the hood so you can execute it perfectly on the first try.
1. Will LAN Bypass cause DNS Leaks?
No, if configured correctly.
DNS (Domain Name System) is what translates tiktok.com into an IP address. ADB does NOT use DNS. ADB connects directly via a raw local IP (like 192.168.1.15:5555).
When you enable "Bypass LAN" (or "Bypass Private IPs") in Nekobox, you are simply telling Android's routing table: "If traffic is going to 192.168.x.x, send it directly to the local WiFi router. If traffic is going anywhere else, send it through the SOCKS5 proxy."
As long as Nekobox is set to use Remote DNS (which it usually is by default for SOCKS5), all requests for external websites will still securely resolve through the proxy. No leaks.
2. How do Wireless ADB and Proxies coexist?
Think of your Android phone as having two separate roads:
Road A (Physical WiFi - wlan0): Your phone connects to your home router and gets a local IP (e.g., 192.168.1.15). Your PC is on the same router. Your PC sends ADB commands down this road.
Road B (Virtual Proxy Tunnel - tun0): Nekobox uses Android's VpnService API to create a virtual network adapter. When an app (like IG or TikTok) tries to reach the internet, Android forces it down Road B. The app thinks it is in the UK/USA.
Because of the LAN Bypass rule, Road A and Road B never intersect. The app has no idea Road A (ADB) even exists, and the SOCKS5 proxy has no idea you are controlling the screen locally.
The Hardware Catch for Wireless ADB:
If you drop the USB hubs and go 100% wireless, your WiFi router becomes the new bottleneck. If you connect 10-20 phones to a cheap ISP-provided router, it will crash. If you go this route, buy a dedicated Wi-Fi 6 Router (like an Asus RT-AX series or TP-Link Archer) and put the phones on the 5GHz band. This will give you rock-solid ADB connections for 24/7 loops.
You can test this on ONE phone first. Connect via Wireless ADB, enable Nekobox with LAN bypass, and run your script while checking whoer.net on the phone's browser. You will see the proxy IP holds perfectly while the script runs via WiFi.
Click to expand...
Thank you so much man, you saved me a lot of time, i already do have a tp-link archer ge400 running on fiberlink 2.5gbps so that should do the trick, and i can just charge the phones on a simple power strip. Appreciate the info bro <3<3<3
 
One thing I'd add if you're planning to scale beyond just a few devices: don't rely on adb devices order. Devices can reconnect in a different order after a disconnect or reboot.
It's much more reliable to identify each phone by its serial number and have one worker/process per device. That way a single reconnect won't affect the rest of the farm, and recovery becomes much simpler.

We've found that designing every worker to tolerate temporary ADB disconnects is much more important than trying to prevent every disconnect in the first place.
 
since you are going the wireless route and keeping them plugged into a strip 24/7, definitely keep an eye on battery swelling. samsungs are notorious for bloating if they sit at 100% charge all day. if they are rooted, use ACC to cap the charge at 50 or 60 percent. if not, maybe get some smart plugs to cycle the power off a few times a day to let them drain a bit. also, make sure you turn the screens off or dim them to the absolute lowest while the scripts run. the heat from the screen plus charging will cause them to thermal throttle, and then your python scripts are gonna start timing out anyway.
 
Good point. Thermal throttling is often overlooked. Once the phone gets hot, UI interactions become less predictable and even simple automation starts taking longer than expected.


We've had better results by reducing screen brightness, removing thick cases, and giving the devices enough spacing for airflow instead of packing them too closely together.
 
gooroo said:
Hi, i do not know if this is the right thread, sorry if it is not but i do not know where to post this. I have a little issue on which i need some help figuring out.

I am running python scripts via ADB on different samsung devices, light scripts, 250lines per script max, they mostly do: switch between apps, change settings, click some things, etc, in an infinite loop. These phones are connected on proxies, so i cannot use wireless debugging as far as i know, only USB debugging (for adb connection)

What i want to do basically: get some kind of usb hub, plug it into a wall outlet, so the hub gets power, plug it in a USB 3.0 port in my PC, and connect all the phones to the hub, so they have stable power supply from the wall outlet, and stable connection to ADB, using only 1 PC port. Asked chatbots but i get vague answers and do not know if this thing is stable

PC specs: r7 9700x, msi b650-a wifi, msi psu 850w, rtx 5070, 32gb ram ddr5 6000mt, many USB 3.0 ports but i'd rather get a hub and keep everything clean and tidy.

Would there be an issue with transfer speeds, power cutoffs, scripts breaking, adb failing, etc? What hubs would yall recommend? Is my idea good, or are there better alternatives? Any idea/suggestion would be highly appreciated, thank you ❤️
Click to expand...
the other piece of advice that could help is ading a simple heart beat test to the code. If the system do not respond for some minute, you will be able to automatically rebot the worker without doing it yourself.
 
I like the heartbeat idea. We ended up doing something similar.


Instead of assuming every ADB command succeeds, each worker reports its last successful action. If there's no progress for a certain amount of time, we restart only that worker or reconnect that specific device instead of restarting the whole process.


It makes long-running automation much more resilient, especially when one device misbehaves while the rest are still working fine.
 
Advertise on BHW
You must log in or register to reply here.
Sign up now!

Main Menu

Home Main Forum List Black Hat SEO White Hat SEO BHW Newbie Guide Blogging Black Hat Tools Social Media Downloads

Marketplace

Account Selling Content / Copywriting EBooks / Methods Hosting Misc Proxies For Sale SEO - Link building SEO - Packages Social Media Social Media - Panels Web Design More

Making Money

Affiliate Programs Hire a Freelancer IM Journeys Making Money Pay Per Click Site Flipping Want to Buy

BlackHat World

Dispute Resolution Forum Suggestions & Feedback Introductions Lounge
Back
Top