Nine hundred screenshots sit in one folder, each named by timestamp, and you want them filed by month. Settings has no switch for that. It is the shape of job a small Python script on a phone is good at: files, text, a web request, a notification at a fixed hour. The first one takes ten minutes. Having it still run next week is harder, and most of this page.
Pydroid 3 by Lider Soft KZ is the one you tap: Contains ads and In-app purchases in its header row, 4.4 stars from about 86,100 ratings, updated 18 May 2026. Its listing describes an offline Python 3 interpreter, pip with a repository of prebuilt scientific wheels, and a terminal emulator. It says nothing about running a script on a schedule or after a reboot.
Termux by Fredrik Fornwall is a different kind of thing: 4.5 stars from about 169,000 ratings, no ads or purchase label in its header row, updated 21 June 2026. It describes terminal emulation with a Linux package collection and a base system that unpacks on first start, after which packages install with apt. Python is one of thousands, and the schedulers arrive with the environment.
So Pydroid 3 is for writing and running, Termux for leaving something running. To compare editors instead, the code editor roundup covers twelve.
The current position is not the one most guides describe. The project's README on GitHub heads a section Google Play Store, experimental branch: that build is for Android 11 and newer, adjusted extensively to pass policy requirements, under development, with missing functionality and bugs compared with the stable F-Droid build, and most users who can should still take F-Droid or GitHub.
The dates cut against the usual advice. F-Droid's newest Termux build, 0.119.0-beta.3, was added on 29 May 2025, while the Play listing says updated 21 June 2026. Follow the recommendation anyway, but not for the usual reason: a newer date on an experimental branch is not the same thing as a stable release.
Do not mix sources. The README says Termux and every plugin share one user id and must carry the same signature, so an F-Droid Termux with a GitHub plugin refuses to install. The app store roundup covers F-Droid and Obtainium, and the 2026 sideloading changes explain the verification check now landing on installs from outside Play.
Termux does not read the battery, post a notification or touch the clipboard. Termux:API does. Its F-Droid page describes exposing basic Android functionality, such as sending SMS or accessing GPS data, to the main Termux app, and lists text to speech, vibration, the clipboard and contacts too. It is two installs, not one: a package also goes inside Termux, with apt install termux-api.
The commands live in the project's termux-api-package repository, whose scripts folder holds roughly sixty, among them termux-battery-status, termux-notification and termux-job-scheduler.
It is a separate app for permissions too: F-Droid's list for it includes background location, body sensors, camera and placing calls, none of which comes with Termux. Grant only what a script needs; how to check what an app can access on Android shows where those grants are listed once an app is installed. Neither plugin is on Google Play.
A fresh Termux cannot see your Downloads folder. One command changes that: termux-setup-storage, whose usage text says to run it without arguments to ensure the storage permission is granted and that symlinks to storage appear in your home directory.
Then the warning worth reading twice. A script runs with your access, not less. It reaches everything you have granted, and pip pulls packages written by strangers onto the device holding your photos and messages. Android's app sandbox still applies, so a script cannot read another app's private data, but it can do anything Termux has been granted, which after the setup command is all of your shared storage.
Check results against the filesystem rather than the log, because a decent file manager makes four hundred files in the wrong folder obvious. If the job is a real backup rather than a tidy up, start from the backup guide: a second copy on the same phone is not one.
Running a script once is easy. Running it at seven every morning is the work, and there are three routes.
That is the ceiling for the whole idea: approximately, and no oftener than once a quarter of an hour. A daily digest or an hourly check fits. Anything that must fire at seven exactly does not.
Plenty of people arrive at Python wanting a result, not a language. If the sentence in your head is turn the Wi-Fi off when I leave the house, three apps get there faster without a terminal.
Tasker by joaomgcd is the veteran, 4.0 stars and 4.49 US dollars on Play after a seven day trial. Its listing claims more than 130 states and events as triggers, among them the app you are in, the time of day, location and your Wi-Fi network, against more than 350 actions.
MacroDroid by ArloSoft is friendlier and carries Contains ads and In-app purchases: 4.4 stars, more than 120 triggers, 200 actions and 80 constraints. Its stated limit is five macros free, then a one time payment for unlimited.
Automate by LlamaLab is the flowchart one, 4.6 stars with In-app purchases and no ads label. You connect blocks, more than 410 by its own count, and its listing names starting tasks on a schedule, and lists executing shell commands as a last resort for apps with no plug-in, so a flowchart can trigger a script rather than replace it.
If the job is a switch, use a switch. Python earns its keep on files, text and logic.
Everything above is a request to the operating system, not a contract. Android's scheduler promises approximately, and a wake lock does nothing once the process is gone. Start with what you control: moving Termux to Unrestricted in Android's per app battery screen is the setting Android offers for something that has to keep running. The battery drain guide has the paths for Pixel and One UI, and the warning that goes with them.
The setting is not the end of it. DontKillMyApp exists because, in its own words, some Android manufacturers prefer battery life over proper functionality of your apps, and it scores them: Huawei, Xiaomi, OnePlus and Samsung worst, Oppo just behind, stock Android and Pixel at zero.
A scheduled script on a phone is something the operating system permits for now rather than something you own, and the manufacturer gets a vote you cannot appeal. Write jobs that lose nothing when a run is skipped, have each one record that it ran, and keep whatever must happen on time on a machine with a mains plug.
No. Pydroid 3's Play listing describes an offline Python 3 interpreter with pip, and Termux's a Linux environment where packages install through apt. Neither names root, and Tasker's listing states that root is not required for the majority of its functions.
Not according to the Termux project. The Termux README on GitHub calls the Play build an experimental branch for Android 11 and newer, built from a separate repository, under development, with missing functionality and bugs compared with the stable F-Droid build. It points most users to F-Droid or GitHub.
Almost always because Android stopped the process. Termux can ask to ignore battery optimisations and hold a wake lock, described by its own command as preventing the CPU from sleeping, but the manufacturer's battery manager decides. DontKillMyApp rates Huawei, Xiaomi, OnePlus and Samsung worst, and Pixel and stock Android at zero.
Termux:API is a separate add-on app for Termux, needed only when a script has to touch the phone. Its F-Droid page describes exposing basic Android functionality such as sending SMS or accessing GPS data to Termux, and lists text to speech, vibration, the clipboard and contacts too. It is not on Google Play.
No oftener than every fifteen minutes, scheduled the way Android prefers. The help text for termux-job-scheduler, which hands timing to the Android job scheduler, says a job runs approximately every period you set and that the minimum since Android N is 900,000 milliseconds. A cron daemon inside Termux can be finer, but fires only while that process is alive.