I wrote about driving a real device with adb to run social automation. That post ended at "the CAPTCHA checkpoint is the wall." This is what's on the other side of the wall — an account got fully disabled, and I had the cause completely wrong.
One question first. Does your automation look like a real finger, or is it just hitting coordinates? I assumed those were the same thing.
My wrong hypothesis: "it got flagged for doing too much"
When the account was disabled, my first move was "cut the volume." Lower the caps, widen the gaps. Then came the decisive counter-evidence.
A human did dozens of follow-backs and follows by hand on that same account, spread across days — and nothing happened. The bot did fewer and got flagged.
So the count can't be the cause. The difference between a real hand and the bot isn't quantity — it's the fingerprint.
What an adb tap actually is
Pull apart the touch event adb shell input tap x y produces:
- Pressure 0. A real finger carries a pressure value.
- Contact area 0. A finger leaves an elliptical contact region.
- Velocity 0. Down and up are effectively simultaneous. Humans take time to press and release.
- Integer pixels, perfectly straight. Swipes are ruler-straight.
This is what the platform's anomaly ML looks at. Not "how many times" but "did this touch come from a human hand." Synthetic input leaves a fingerprint right here.
The trap I set for myself
Worse: an optimization I added "to start from a clean state" actually amplified the signal.
Every time I switched accounts, I force-stopped the app and relaunched it. Cold launch → straight to the followers list → follow-back spree. Humans don't force-stop apps. They open it and browse the feed first. "Kill the app, relaunch, immediately do bulk actions" is something a person never does — I'd hand-added a bot signal.
Other signals stacked on top:
- Marching down the list at a fixed X. I pinned the button at x=814 and only moved y down. That's a machine march.
- Rapid multi-account switching on one device. The platform bundles this into a connected-account cluster.
- Zero browsing noise. No feed scroll, no pauses, straight to the followers list.
What would you do?
Here's the fork. Do you add a bit more jitter to the tap coordinate and tell yourself "that looks human enough" — or do you accept that synthetic touch has a ceiling you can't cross?
I chose the latter. I did everything I could:
- Reset-per-account → back to once per burst (removed the cold-launch-straight-to-action signal).
- Injected browsing noise — scroll the feed a few times and pause randomly before diving into the followers list.
- Tap a random point inside the button — no more fixed-X descent.
And the part I'll say honestly: the synthetic touch itself — pressure and velocity of zero — can't be fixed with input tap. You could mimic pressure at a lower level (sendevent), but it's device-fragile and brittle. A ceiling is a ceiling.
A real finger passes
The disable screen had a "confirm you're human" step. This has to be solved by a person on that device. A bot solving it? That's detection evasion, and it only makes the ban worse.
And that proves this post's whole point. Same screen, same account — press it with a real finger and it passes. Because there's pressure, velocity, a contact area. The check a bot can't cross, a human hand just crosses. A few days later the account was restored, with a note that "the activity does follow our standards."
Yet Threads is fine
Same device, same adb, same company's infrastructure — but the Threads automation keeps running fine. What's the difference?
Threads follows the authors of topic search results — not random cold follows, but people whose interests overlap. And it runs at human speed, in time-boxed bursts, at low volume. Different character, different risk. I don't get complacent, though — it shares the same synthetic touch fingerprint. So right after a disable event, I watch Threads conservatively too.
Three self-checks
Check whether your UI automation looks human, right now.
- Do you do the target action immediately after a cold launch? Humans open an app and look at something first.
- Are your tap coordinates fixed? Same pixel repeated = fingerprint. Scatter them inside the button.
- Is there any aimless browsing between actions? Zero scrolls and pauses is itself a signal.
The honest part
Even with every fingerprint mitigation in place, the fundamental ceiling stays. input tap is, in the end, not a real finger. So the conclusion is less about technique and more about posture — automation that burns the account isn't automation, it's a loss. Do with the official API what the API allows (it's safe); use device control only for the small things the API won't open, at human speed, with layered safety nets. However well you build a self-learning growth loop, it only means something on top of that principle.
Check just one thing right now. In your automation logs, are the last ten tap coordinates all the same X? If so, the platform is looking at that too.