Turning an Always-Plugged-In Android Phone into a Bot Device

Most of us have an old Android phone sitting in a drawer. I plugged mine into the Mac mini I keep at home, left it there, and turned it into a dedicated automation phone that a bot controls through adb. You don't need a Mac mini, though. Any computer that runs adb works the same way.

A phone a person carries and a phone a bot uses need very different settings. If the screen turns off or locks, the bot just stops. Here's how I set up a Galaxy S23 to be bot-friendly, step by step.

Menu names follow Samsung's One UI, so they may differ a bit on phones from other manufacturers.

adb (Android Debug Bridge) is the official tool for sending commands from a computer to an Android device. You can install apps, tap the screen, type text, and manage files, all from the terminal.

Phone settings: keep the bot from getting stuck#

I removed the screen lock entirely#

The lock screen is where bots get stuck most often. At first I kept my pattern lock and tried the "trusted places" option in Extend Unlock (Smart Lock). It keeps the phone unlocked while you're at a location you've marked as home.

But the phone kept locking even with location turned on. When I looked into it, there were several reasons.

1. First unlock — Right after a reboot, you have to unlock it manually once, even in a trusted place.
2. The 4-hour rule — Even with Extend Unlock, the phone locks again if you haven't unlocked it manually for 4 hours.
3. Reboots — If the phone reboots for an update or anything else, you're back to case 1.
4. Location accuracy — Indoors, the location can drift and the phone decides you're "not at home."
5. Battery optimization — Power saving can keep location services from updating on time.

On a phone you carry every day, the 4-hour rule barely matters. On an automation phone nobody touches, it's a dealbreaker. Since this phone never leaves the house, I set the lock to None.

Three changes in Developer options#

Go to Settings → About phone → Software information and tap Build number seven times to unlock Developer options. I changed three things there.

1. Stay awake — The screen stays on while charging. Since the phone is always on USB, it's effectively always on.
2. Maximum screen timeout — I also set the screen timeout in Display settings to the longest option.
3. Animation scale 0 — Turn off window animation scale, transition animation scale, and animator duration scale, and screen transitions finish instantly. The bot spends less time waiting for the screen to change.

You can also set the animation scales with adb.

# Set all three animation scales to 0
adb shell settings put global window_animation_scale 0
adb shell settings put global transition_animation_scale 0
adb shell settings put global animator_duration_scale 0

Protecting the screen and battery#

A screen that's always on raises the risk of burn-in (a ghost image left behind when the same content stays on screen too long). So I turned brightness all the way down.

For the battery, I used Protect battery to stop charging at 79%. A phone that sits on a charger all day wears its battery out faster if it stays at 100%. Finally, I turned on Do not disturb so notifications don't cover the screen.

Computer settings: make adb easy to use#

My setup is macOS with zsh, so the examples below assume that. On another OS, just adjust the paths and install steps for your environment.

The adb path and a zsh function#

If you installed the SDK through Android Studio on macOS, adb lives here.

~/Library/Android/sdk/platform-tools/adb

At first I stored my common command in a string variable, but that didn't work as expected in zsh. Unlike bash, zsh doesn't split unquoted variables on spaces. So if you set ADB="adb -s serial" and then run $ADB shell ..., zsh treats the whole string as a single command name.

A function is the cleaner fix.

# ~/.zshrc
# Replace <serial> with the device serial from adb devices
phone() {
  "$HOME/Library/Android/sdk/platform-tools/adb" -s "<serial>" "$@"
}
 
# Example
# phone shell input tap 500 1200

Viewing the phone screen on your computer with scrcpy#

scrcpy mirrors a USB-connected Android screen in a window on your computer and lets you control it with your mouse and keyboard. It's handy for checking what the bot is doing. It also runs on Windows and Linux; I'm on macOS, so I installed it with Homebrew. The version I got was 5.0.1.

brew install scrcpy

scrcpy uses adb under the hood, so adb needs to be on your PATH. Add the SDK's platform-tools directory to PATH.

# ~/.zshrc
export PATH="$HOME/Library/Android/sdk/platform-tools:$PATH"

Now just type scrcpy in the terminal and the phone shows up on your computer's screen.

Typing Korean with ADBKeyBoard#

adb has an input text command, but it can't type Korean properly. So I installed a separate input method app called ADBKeyBoard. It's a keyboard that types whatever string it receives through an adb broadcast.

The Play Protect warning#

When I tried to install it, Play Protect blocked it with an "Unsafe app blocked" warning. The warning showed up because the app was built for an older Android version.

After checking what the app does and where it came from, I installed it via "More details → Install anyway." I'll come back to that decision in the cautions section below.

Typing a full Korean sentence at once#

ADBKeyBoard accepts Base64-encoded strings through the ADB_INPUT_B64 broadcast. Sending Base64 keeps Korean characters, spaces, and special characters from getting mangled by the shell.

# Switch to ADBKeyBoard only while automating
adb shell ime enable com.android.adbkeyboard/.AdbIME
adb shell ime set com.android.adbkeyboard/.AdbIME
 
# Base64-encode a Korean sentence and type it in one go
adb shell am broadcast -a ADB_INPUT_B64 \
  --es msg "$(printf '%s' '안녕하세요, 자동화 테스트예요' | base64)"

I keep Samsung Keyboard as the default and switch with ime set only while automating. When the job is done, switch back to Samsung Keyboard. You can look up input method IDs with adb shell ime list -s.

What I actually use it for#

Generating CapCut TTS audio#

Some of CapCut's TTS voices (like "Adam") are only available in the mobile app. So I have the bot drive the CapCut app through adb to generate the audio and export it. The phone becomes a bridge for work I couldn't do on the desktop, and it runs automatically.

Cleaning up the gallery#

Automation runs leave exported files piling up in the gallery. Even after you delete files with adb, they keep showing up in the gallery app for a while, because the media index the gallery reads doesn't update right away. So I rerun a media scan after deleting files to bring the list back in sync.

Cautions worth knowing#

The convenience comes with trade-offs.

1. A device with no lock — If you lose this phone, anyone can open it. Only do this on a device that never leaves the house, and don't sign into important accounts or payment methods on it.
2. Bypassing Play Protect — Only ignore the warning for apps whose source and behavior you've checked yourself. If you get used to "it installs anyway," real malware can get in the same way.
3. App automation and terms of service — Driving another company's app with a bot may violate that platform's terms of service. Check the terms before you automate.
4. Hiding personal info — When you share a setup like this, hide details like the device serial or the username in your file paths.

Wrapping up#

In short, a bot phone needs three things: it shouldn't lock, it shouldn't turn off, and it should last. Add an adb function, scrcpy, and ADBKeyBoard on top, and your computer can use the phone almost like a remote hand.

If you have a phone in a drawer, start by turning on "Stay awake" in Developer options. Automation gets a lot easier from there.

I endeavour to be wise when I cannot be merry, easy when I cannot be glad, content with what cannot be mended and patient when there is no redress.

— Elizabeth Montagu