How to Automate Common ADB Tasks with Tasker on Android (No Root)

Many Android power users love ADB because it lets you run low‑level commands without opening a terminal on the device. The downside is that ADB is usually a manual, one‑off tool – you connect a PC, type a command, then disconnect. Tasker can bridge that gap by triggering ADB commands from the phone itself, turning a series of keystrokes into a hands‑free routine.

Before you start

• Device requirements: Android 7.0 or newer. The steps work on most manufacturers; wording may differ on Samsung’s One UI or Xiaomi’s MIUI.
• Battery: Keep the phone charged above 50 % or plug it in. Some ADB commands (e.g., reboot) will interrupt charging.
• Network: Both the phone and the PC (if you use one for the initial ADB setup) must be on the same Wi‑Fi network.
• Permissions: You need to enable Developer Options and USB debugging. No root is required.
• Tasker version: The free trial works for testing, but the full version (paid) is needed to use the Run Shell action with Use Root unchecked.

Step 1 – Enable Developer Options and ADB over Wi‑Fi

1. Open Settings → About phone → tap Build number seven times. You’ll see a toast confirming “You are now a developer”.
2. Return to the main Settings screen, then go to System → Developer options (on some skins it appears directly under Settings).
3. Toggle USB debugging ON. Confirm the security dialog that appears.
4. Scroll down and enable Wireless debugging (Android 11+). For Android 10 and earlier, you will use the classic “ADB over network” method.
   • Android 11+: Tap Pair device with pairing code, note the IP address and pairing code.
   • Android 10‑: Keep the phone connected to a PC via USB for the first time (see step 1‑e).
5. If you are on Android 10‑, connect the phone to a PC with a USB cable, open a terminal on the PC, and run:

   adb devices

   You should see your device listed. Then enable TCP/IP mode:

   adb tcpip 5555

   Disconnect the USB cable. Your phone is now listening for ADB connections on port 5555.
6. Find the phone’s local IP address: Settings → Network & internet → Wi‑Fi → tap the connected network → scroll to “IP address”. Remember the address (e.g., 192.168.1.42).
7. From the PC (or from any Android device that has adb installed via Termux), test the connection:

   adb connect 192.168.1.42:5555

   You should see “connected to 192.168.1.42:5555”. If you get “unable to connect”, double‑check the IP and that the phone’s firewall isn’t blocking port 5555.

Step 2 – Install Termux and the ADB binary on the phone

Tasker cannot call adb directly because the binary lives on a PC. The workaround is to install the ADB client locally via Termux, then let Tasker invoke it through a Run Shell action.

1. Open the Google Play Store (or F-Droid) and install Termux.
2. Launch Termux. The first launch will download additional data – wait until the prompt returns.
3. Update the package list and install the ADB tools:

   pkg update && pkg upgrade -y
   pkg install android-tools

   This places the adb executable in $PREFIX/bin.
4. Give Termux the permission to access your storage (required for some commands that read/write files):

   termux-setup-storage

   Accept the Android storage permission dialog.
5. Test that the local ADB client can see the device itself (loopback). Run:

   adb devices

   You should see a line like 127.0.0.1:5555 device. If not, run adb start-server first.

Step 3 – Grant Tasker permission to run shell commands

Tasker’s Run Shell action can execute any command that the app’s process is allowed to run. Because we are not using root, the command must be executable by the regular app user. The ADB binary installed in Termux is accessible to other apps only if we place a symbolic link in a location that Tasker can read, such as /data/local/tmp. Android blocks write access to that folder for non‑system apps, but we can use the run-as trick on a debug build, or simply copy the binary to the app’s private files directory and reference it via its full path.

1. In Termux, create a small wrapper script that forwards arguments to adb:

   cat > $HOME/adb-wrapper.sh <<'EOF'
   #!/data/data/com.termux/files/usr/bin/sh
   exec /data/data/com.termux/files/usr/bin/adb "$@"
   EOF
   chmod +x $HOME/adb-wrapper.sh

2. Move the script to a location readable by Tasker, e.g., the shared storage folder:

   mv $HOME/adb-wrapper.sh /sdcard/adb-wrapper.sh

   Tasker can read files from /sdcard without extra permissions.
3. Open Tasker and create a new Profile → Event → choose a trigger (we’ll use Time later).
4. Add a new Task and name it “Run ADB Command”.
   • Tap + → Code → Run Shell.
   • In the Command field, type the full path to the wrapper and the ADB arguments you need, for example:

     /sdcard/adb-wrapper.sh shell settings put global airplane_mode_on 1

   • Leave Use Root unchecked.
   • Enable Store Output if you want to capture the command’s result for later use.
5. Save the task. When the profile triggers, Tasker will launch the wrapper, which in turn runs the ADB command inside Termux’s environment.

Step 4 – Practical examples

Below are three common automation scenarios that illustrate the power of combining ADB with Tasker.

Example 1 – Toggle Airplane Mode at a specific time

1. Create a new Profile → Time → set 22:00 as the start time.
2. Add the “Run ADB Command” task created earlier.
3. In the Command field, use:

   /sdcard/adb-wrapper.sh shell settings put global airplane_mode_on 1 && /sdcard/adb-wrapper.sh shell am broadcast -a android.intent.action.AIRPLANE_MODE --ez state true

   The first part updates the system setting; the second part broadcasts the change so the UI updates immediately.
4. Optionally add a second profile at 07:00 that runs the same command with 0 (disable) and false.

When the time arrives, Tasker runs the command without any user interaction, effectively automating a “Do Not Disturb” window.

Example 2 – Clear cache of a specific app when storage gets low

1. Profile → Event → Variable Set. Use the built‑in variable %FREE_SPACE (Tasker can compute free space via Java Function or a small shell script). Set the condition %FREE_SPACE < 500 (megabytes).
2. Task → Run Shell with command:

   /sdcard/adb-wrapper.sh shell pm clear com.example.app

   Replace com.example.app with the target package name.
3. Enable If condition to run only when the device is charging, using the built‑in %CHARGING variable.

This automation helps prevent “low storage” warnings by regularly cleaning cache of a heavy‑use app (e.g., a podcast player).

Example 3 – Launch an app with a specific permission granted

Sometimes you need to grant a runtime permission before an app starts, otherwise the first launch shows a dialog that blocks automation. ADB can grant permissions silently.

1. Profile → Application → select the target app (e.g., com.whatsapp).
2. Task → Run Shell with command:

   /sdcard/adb-wrapper.sh shell pm grant com.whatsapp android.permission.READ_CONTACTS

3. Add a second Run Shell action to launch the app:

   /sdcard/adb-wrapper.sh shell monkey -p com.whatsapp -c android.intent.category.LAUNCHER 1

Now, whenever you tap the WhatsApp icon, Tasker first grants the contacts permission (if not already granted) and then opens the app, removing the permission dialog.

Step 5 – Verify that the automation works

1. Manually run the task from the Tasker UI (long‑press the task → Run). Observe the expected outcome (e.g., airplane mode toggles).
2. Check the task’s Logcat output: open Tasker → More → Logcat. Look for lines that start with ADB to confirm the command executed without error.
3. If you enabled Store Output, you can add a Flash action after the shell step to display the result, e.g., Airplane mode set: %taskout.

Troubleshooting

• Command not found: Ensure the wrapper script is executable (chmod +x /sdcard/adb-wrapper.sh) and that the path is correct. Tasker’s Run Shell uses the app’s default working directory, so absolute paths are safest.
• Permission denied: The ADB binary inside Termux runs under the Termux UID, which cannot access system settings directly unless the device is rooted. However, many settings put commands work because they are exposed via the ADB daemon. If a particular command fails, check whether it requires root by running it manually in Termux first.
• Device disconnects from Wi‑Fi ADB: Some routers block traffic on port 5555 after a period of inactivity. Keep the phone’s screen on for a minute after the first connection, or add a periodic “keep‑alive” task that runs adb devices every 10 minutes.
• Tasker crashes when running the shell: Verify that the Run Shell action’s Timeout is set high enough (default 10 seconds). Complex commands like pm clear may need 20 seconds.
• Battery drain: Constant Wi‑Fi ADB listening consumes a small amount of power. Disable the “Wireless debugging” toggle when you no longer need automation, or create a profile that disables it at night.

Advanced tips and edge cases

• Running multiple commands in one task: Separate commands with && to ensure the second runs only if the first succeeds. Example:

  /sdcard/adb-wrapper.sh shell settings put system screen_off_timeout 60000 && /sdcard/adb-wrapper.sh shell input keyevent 26

  This sets a 1‑minute screen timeout then immediately turns the screen off.
• Using variables: Tasker variables can be inserted into the command string. For instance, to toggle Wi‑Fi based on a variable %WIFI_STATE:

  /sdcard/adb-wrapper.sh shell svc wifi %WIFI_STATE

  Set %WIFI_STATE to enable or disable earlier in the task.
• Scheduling with Do Not Disturb: Combine the ADB automation with Tasker’s built‑in Do Not Disturb actions to create a “night mode” profile that silences notifications, lowers screen brightness, and disables Bluetooth—all via ADB commands for deeper control.
• Running ADB commands on a different device: If you have multiple Android devices on the same network, you can specify the target IP in the wrapper script:

  adb -s 192.168.1.55:5555 shell <command>

  Create separate wrapper scripts for each device and call the appropriate one from Tasker.

Safety warnings

• Never use the pm uninstall --user 0 command via this automation unless you are absolutely sure you want to remove a system app for the current user. The operation is reversible only by flashing a factory image.
• Changing global settings (e.g., airplane_mode_on) can interfere with ongoing calls or data transfers. Schedule such changes during periods of low activity.
• Storing the wrapper script on external storage makes it readable by any app. If you automate sensitive commands (e.g., granting permissions to a banking app), consider moving the script to the app’s private directory (/data/data/com.termux/files/home) and granting Tasker the READ_EXTERNAL_STORAGE permission to access it via a content URI.

Wrapping up

By installing Termux, exposing the ADB client locally, and using Tasker’s Run Shell action, you gain the ability to run virtually any ADB command without ever touching a PC again. The workflow is fully reversible: disable the “Wireless debugging” toggle or delete the wrapper script to stop automation instantly.

Experiment with the examples above, then adapt them to your own routine – whether it’s silencing the device at bedtime, clearing caches when storage is low, or granting permissions to newly installed apps. The combination of ADB’s power and Tasker’s flexibility turns a static command line into a living, context‑aware assistant on your Android phone.