What the platform actually guarantees, and what it doesn't

Exact scheduling is optional special access; without it Android can delay delivery. Schedules restore after reboot, package update, clock or time-zone change, and app resume.

Charging, battery, Wi-Fi, Bluetooth, headphone, sensor, screen-rotation, and app triggers run a persistent notification with a Pause monitoring action, which pauses event and notification routines while scheduled ones stay enabled. The monitor takes no wake locks and does no aggressive polling. Headphone triggers watch the audio outputs, so a USB-C headset or adapter, or a USB audio device such as a dock or DAC, counts, not only the 3.5 mm jack.

Three Quick Settings tiles each run the routine you choose in Settings, and a home screen widget runs the one you pick when you place it. Home-screen shortcuts, for up to four routines, open the routine's run confirmation. Another app can ask Rulomi to run a routine with the com.rulomi.action.RUN_ROUTINE intent, which also opens the confirmation, so nothing but a tile or a widget runs a routine without your confirming it. Every entry point goes through the same permission and condition checks.

Shake, face down, and face up read the accelerometer, which Android stops delivering once the screen is off and the phone suspends, and Rulomi will not hold a wake lock to keep it. A shake in your pocket does nothing, and turning the phone over with the screen off is noticed when the screen next comes on. Proximity is usually a wake-up sensor, which Rulomi checks at runtime, and where it is one a proximity routine keeps working with the screen off. Android also uses that sensor during calls, so a proximity routine fires when the phone goes to your ear. The light sensor follows the accelerometer's rule and is read only while the screen is on, and a phone lying face down reads as dark. Landscape and portrait come from the screen's own rotation rather than a sensor, so with auto-rotate off they fire only when an app turns the screen.

Notification routines use a NotificationListenerService that Android binds only while notification access is granted, and the monitor notification stays up beside it as the visible sign that Rulomi is listening. The listener ignores Rulomi's own notifications, work-profile and secondary-user notifications, ongoing notifications, group summaries, and media controls, and a routine fires at most once a minute. When Android unbinds the listener, Rulomi asks to be rebound on every resume and every monitor start.

Enabling a routine captures the current state, so it will not run merely because the condition is already true. A sensor state cannot be read without a listener, so the first reading after enabling records the state without firing. A Bluetooth link that drops and re-establishes while connecting settles for five seconds, so one handshake fires a routine once. A device with classic Bluetooth, as most headphones, cars, and speakers have, is connected by its classic link alone; earbuds that play audio over LE Audio alone aren't seen connecting yet.

A wait hands the rest of the run to an AlarmManager alarm, so the steps after it run with the app closed, and permissions and conditions are checked again when it ends. Pausing, editing, or deleting the routine cancels the wait. Restore captures the settings when the run starts and puts them back through the same kind of alarm; it overwrites anything you changed by hand in the meantime, and it does not happen if that alarm is lost.

A routine that starts when something begins can put the settings it changed back when that ends: the app leaves the front, charging stops, the battery is back above the level, the connection drops, the phone is no longer face down, the sensor is uncovered, the screen turns back to portrait, or the light changes back. The settings are captured when the run starts and kept in private storage, not in a backup. Run now never waits for an end, and pausing, changing, or deleting the routine puts them back straight away. If event monitoring was stopped, they go back when it next checks after restarting.

Every routine shows what it leaves the phone set to. Before one is saved, Rulomi warns when two of its steps set the same thing in the same moment, or when another enabled routine fires at the same moment and leaves the setting elsewhere, unless their conditions can never both hold; enabling it anyway takes a tick. A switch turned straight back with nothing between is refused, since nothing would change. Why isn't it working? checks access, event monitoring, the next alarm, battery management, and the last run, and offers the fix where there is one. It sends nothing and stores nothing new.

Execution resumes when the app is opened again. OEM battery management and foreground-service restrictions can also interrupt monitoring. A scheduled run that arrives five minutes or more late says so in Activity, and one that never arrives is recorded as missed and rescheduled. Three late or missed runs in a row, or three monitor restarts by the system, put a card on Home that links to Android's battery-optimization list.

Permissions are checked before any action executes, and then conditions; a run a condition stops is recorded as skipped. A runtime failure stops remaining actions and records how many succeeded; actions already executed are not reversed.

Brightness changes disable adaptive brightness. Each volume action names its stream, and “volume” alone means media. A volume set while Do Not Disturb or the ringer mutes that stream is still stored, and applies once the stream is unmuted. Android treats silent and vibrate as Do Not Disturb states, so ringer mode and the ring and notification volumes need DND access. On Android 15+ DND maps to an app-owned automatic rule that cannot override yours or another app's; on older versions it changes the phone's DND itself.