Two phone routines worth making explicit are unwanted cellular fallback and Do Not Disturb that stays on after a meeting. Wi-Fi normally carries internet traffic without using your mobile allowance; leaving mobile data enabled does not by itself consume it. Some phones can fall back to cellular when Wi-Fi is weak or use a device-specific assistance mode. Check your mobile usage counters before blaming that toggle. Android automation can help with these settings, but its permissions and background limits vary by phone, so build around actions you can test and reverse.
phone automation is not server automation
On a Linux box, a scheduler runs because you told it to and nothing argues. On a phone, battery life is the operating system’s first priority and your macro is a suspect. Android’s Doze mode defers background work when the device is idle, App Standby restricts apps you rarely open, and manufacturers layer their own, more aggressive termination on top of that. Understanding this reframes the whole exercise: you’re not just writing rules, you’re also negotiating permission for them to keep running.
The practical consequence is that automations which react to an event, like connecting to a Wi-Fi network or plugging in a charger, are far more reliable than ones needing precise timing while the screen is off. Design around that and you’ll be much happier.
choosing a tool
| Option | Best for | Catch |
|---|---|---|
| Built-in Modes or Routines (One UI, Pixel, HyperOS/MIUI) | Simple schedules and DND | Limited triggers, varies by brand |
| MacroDroid | Most people, visual trigger-action-constraint builder | Free tier caps active macros |
| Tasker | Deep control, variables, scripting | Steeper learning curve, paid |
| Automate | Flowchart thinkers | Flow layout gets unwieldy when large |
Start with whatever your phone already includes. If the built-in Routines can silence your phone on a schedule, you don’t need an app for that. MacroDroid earns its place when you need conditions the OEM tool can’t express, and its three-part model makes those easy to think about: a trigger starts things, actions happen, and constraints decide whether the macro is allowed to fire at all. Most beginner mistakes come from putting something in the trigger that belonged in the constraints.
five macros worth building first
1. home Wi-Fi arrives, mobile data steps back
First compare cellular usage with stable Wi-Fi and after deliberately disconnecting it. If you want to prevent fallback, a macro can react to your home SSID and request a mobile-data change, with a reverse action on disconnect. Android may forbid that toggle for an ordinary app; use the supported notification or manual action instead of assuming it succeeded. Do not disable a connection you need for emergency or essential communications. Test the exact phone/version and keep a manual way to undo the choice.
2. Do Not Disturb that always ends
The failure is almost never switching DND on, it is forgetting to switch it off. So build the macro around the exit: trigger on DND becoming active, then after a set delay, turn it off. Configure your DND exceptions first so that repeat callers and starred contacts still get through, because a phone that silences family for an afternoon is worse than one that rings in a meeting.
3. low battery triage
Trigger: battery falls below a threshold. Actions: drop brightness, disable background sync, and post a notification. Constraint: only when not charging. Useful on a long day out, and far more predictable than remembering to do it yourself in the queue at a ticket counter.
4. charger connected at night means alarm check
Trigger: power connected. Constraint: time between 10 PM and 1 AM. Action: read out or display whether an alarm is set for tomorrow. Small, and it earns its place the first time it catches a morning with nothing set.
5. a shortcut that tells the house you’re back
Trigger: connected to home Wi-Fi. Action: an HTTP request to your home controller. This is where phone automation stops being a collection of tricks and starts being part of a system, and it pairs directly with the local setup in my Home Assistant guide. If you’re earlier in that journey, the cheaper starting point is in the home automation starter guide.
the part that decides whether any of this keeps working
If your macros fire perfectly for two days and then stop, you have not written a bad macro. The system stopped your automation app while the screen was off. Three settings fix most cases, and they live in different places on every brand:
- Exclude the app from battery optimisation. Usually under Settings, Apps, the app, Battery, then choose Unrestricted or Don’t optimise. This is the single most important step.
- Enable Autostart. On Xiaomi, Realme, Oppo and Vivo phones there is a separate autostart permission, and without it the app will not come back after a reboot or a memory cleanup.
- Lock the app in recents. Several skins let you pin an app so the memory cleaner skips it. On Xiaomi’s HyperOS (and older MIUI) this is the little lock icon in the recents view.
Also stop using the “clear all” button in recents out of habit. On aggressive skins that is a request to terminate your automation. And check these settings again after a system update, because major updates have a way of quietly resetting them, which is how a macro that ran for a year suddenly stops.
A persistent notification from the automation app is not a bug either. It is a foreground service telling Android the app is doing legitimate work, and it is part of why the app survives. You can usually minimise how prominent it looks, but don’t try to remove it.
what Android will not let you automate any more
Being straight with you here saves hours of confusion. Android has progressively closed off toggles that automation apps once controlled freely. Since Android 10, an ordinary app cannot switch Wi-Fi on and off on your behalf; it can only send you to the settings panel. Several other system settings need a permission that a normal installation simply cannot hold, and the workarounds involve either a rooted device or granting a permission over a USB debugging connection from a computer.
I’d suggest treating those workarounds as out of scope unless you understand the trade. Leaving developer options and debugging enabled on a phone you carry has its own risks, and root changes your security model and often your banking apps’ willingness to run. For most people, the better move is to accept that some actions will be a one-tap prompt rather than fully automatic. A macro that opens the right settings screen and shows a notification is still a genuine improvement over remembering.
permissions you will need
Notification access, for macros that react to a notification arriving. Do Not Disturb access, for anything touching ringer modes. Location, if you use geofence triggers, and on recent Android that means allowing background location, which you should think about before granting. Accessibility service, for a few UI-driven actions, and this one deserves real caution: an accessibility service can observe a great deal of what happens on screen. Grant it only to an app you trust and only while a macro needs it.
common mistakes
- Building eight macros in the first sitting. Build one, live with it for a week, then add the next. Interactions between rules are where the confusion starts.
- Putting conditions in the trigger instead of the constraints, which produces a macro that fires at the right moment on the wrong day.
- Two macros that undo each other. One turns Wi-Fi-related settings on, the other off, and the phone sits in a loop. Give each a clear constraint so only one can apply at a time.
- Automating anything safety-related. Don’t route emergency calls, medical reminders or alarms through a macro that a memory cleaner can kill.
- Ignoring what the phone sends out. If you care about the chatter from apps on your network, filtering at the DNS layer as in my Pi-hole setup guide does more for privacy than any phone macro will.
FAQ
Does this drain my battery?
Event-based macros cost very little, because the app is waiting on a system broadcast rather than polling. What does cost battery is frequent location checks for geofences and any macro that wakes the phone every minute. If you notice a difference, look at those two categories first. Several of the macros above exist specifically to save battery, so a well-chosen set usually comes out net positive.
Is the free version enough?
For learning, yes. MacroDroid’s free tier limits how many macros you can keep active, which is a reasonable constraint while you work out which ones you actually use. The upgrade is a one-time purchase rather than a subscription, and I’d only buy it after a couple of weeks when you know the tool suits how you think.
Will my macros survive changing phones?
Export them. Most of these apps can write your macro set to a file, and that file is worth keeping alongside your other backups. Expect to redo the permission and battery settings on the new device from scratch, and to adjust anything that referenced brand-specific behaviour, since moving between skins changes more than you’d like.
Can I trigger something on my home server from my phone?
Yes, with an HTTP request action pointed at a webhook. Keep that endpoint on your own network or behind a tunnel with a token rather than exposing a service to the open internet, and treat the token as a credential. This is the cleanest bridge between a phone and a home lab, and it avoids giving a third-party service control over anything in your flat.
Build the Do Not Disturb exit macro first, because it’s the one most likely to save you an embarrassing missed call this month. Then set the battery exclusions properly, or you’ll spend next weekend wondering why a working macro stopped working.
Update history: added Xiaomi’s HyperOS alongside MIUI in the tool table and the recents-lock step.
Sources
- Doze and App Standby documentation — how Android defers background work on an idle device, and what it means for scheduled tasks.
- Android 10 privacy behaviour changes — including the restriction that stops ordinary apps toggling Wi-Fi.
- Don’t kill my app — a per-manufacturer reference for the background termination behaviour described above.