Shappky kills background apps through Shizuku or root, and automates it

Shell App Killer, and what it actually executes

Shappky, short for Shell App Killer, is an app that stops background applications using either Shizuku or root permissions, with the stated goals of improving device performance, reducing memory usage and lowering heat, in what the README calls a lightweight and safe way. The mechanism is the important part, and the README is unusually direct about it: the app relies heavily on shell commands to identify and kill applications, and it points to a separate document, `docs/how_shappky_works.md`, for the details. That is a deliberate design choice rather than a shortcut. Most memory-cleaning utilities on Android ask for accessibility services or use the standard force-stop intent. Shappky instead runs the same class of command a developer would run from a terminal, which is why it needs those permissions in the first place. The audience is a user with a rooted device or a Shizuku setup who wants control over what runs in the background and when.

Two permission paths, one set of consequences

The flexible permissions feature is the first on the list: it works with either Shizuku or Root access. The distinction matters more than it sounds. Root gives the process direct system privileges, and with it the ability to do anything the shell allows, including things that can break a running system. Shizuku is the lighter of the two, running its service through the Android service manager so that shell-level commands work without a permanent root install, and it is the option the README's ordering puts first. The stated requirement is the same either way, and it is a hard one: Shappky requires Root or Shizuku permissions to work. So this is not an app for a stock device, and the requirement list says so plainly alongside Android 7.0 or higher. For an evaluation, that single fact is the screening criterion, because there is no fallback mode and no degraded experience without one of the two.

Triggers, the service and the Quick Tile

The automation model is where the app goes beyond a manual cleaner. There are two trigger types. A profile trigger must be executed manually, letting you select a specific group of apps to act on. A service trigger lets you create and customise a background service using available rules, with automatic enable and disable options based on those rules. The background service itself runs in the background and automatically stops active apps once enabled, and its general options can be customised, though the app-killing rules are not customisable inside the service itself. The README points out the way around that: if you want full control over service behaviour, you create a Service Trigger with custom rules instead. The Quick Tile is the low-friction entry point, activating the background service that automatically kills unused apps. Together these give you three levels of intervention, from a manual one-tap kill of a chosen group, to a rule-driven service, to a tile you can hit from anywhere.

Protecting the apps you did not mean to kill

The app protection feature is the one that separates this from a brute force cleaner. You can protect certain apps from being killed, and the README names the examples: the keyboard, the launcher, and core system services. Those three are exactly the set of processes whose termination would make a device unusable rather than merely slow, and it is telling that they are the ones the documentation calls out. A cleaner that kills your launcher looks broken, and one that kills your keyboard leaves you unable to type a password to fix it. For a tool whose whole job is terminating processes, an explicit exclusion list is not a nicety. The screenshots in the repository show the main interface, so you can see how the list is presented before committing to the app.

Driving it from Tasker, intents and widgets

Three integration surfaces extend the app beyond its own interface. Tasker support is described as full support for integration and custom actions, and the setup path is a plugin: create a new Task, select the Shappky plugin, tap Configure, and choose the action. The Intent surface uses a Broadcast Intent, and the package name is `com.yassernull.shappky`. The available actions are named, and they map onto the trigger and service model. `com.yassernull.shappky.EXECUTE_TRIGGER` runs a profile trigger, `com.yassernull.shappky.ENABLE_TRIGGER` and `com.yassernull.shappky.DISABLE_TRIGGER` turn a service trigger on and off, and `com.yassernull.shappky.ENABLE_SHAPPKY_SERVICE` and `com.yassernull.shappky.DISABLE_SHAPPKY_SERVICE` do the same for the service itself. The extra key is `TRIGGER_NAME`, and you enter the trigger name. The widgets are two. The action widget is a 1x1 shortcut with a profile trigger assigned to it, so tapping it executes that trigger. The app list widget puts the list of running background apps on the home screen with a one-tap kill.

Installing from the releases page

There is no install command here, because there is nothing to compile. The installation section says you can download and install Shappky via one of the following methods, and names one: GitHub Releases, where you download the latest APK from the Releases page. The repository layout is a standard Android project, with an `app/` module, `build.gradle.kts` and `settings.gradle.kts` in Kotlin DSL, a `gradle/` directory with the wrapper scripts `gradlew` and `gradlew.bat`, a `fastlane/` directory for release metadata, a `docs/` directory holding the images and the `how_shappky_works.md` explanation, and a `CHANGELOG.md`. The primary language is Kotlin. So a developer who wants to build it locally uses the Gradle wrapper in the repository, and everyone else takes the signed or unsigned APK from the releases page and installs it directly, which on a rooted or Shizuku device is a familiar operation. The release history shows v1.1.0 in July 2025, v1.2.0 in August 2025 and v2.0.0 in August 2026, and the last push to the repository was on 2026-10-19.

What the documentation does not settle

The README is a good summary and the linked document is the place with detail, and a few things a prospective user would want are not answered in the summary. The exact commands executed are documented in `docs/how_shappky_works.md` rather than in the README itself, and the README does not say which system processes the app considers safe to stop, beyond the protected list. It also does not describe what happens to an app that is killed while holding unsaved state, or how the service behaves when Shizuku is restarted, which is a real operational concern because Shizuku stops whenever the device reboots. Whether there is an option to auto-start the service on boot is not stated. The project is GPL-3.0 licensed, which is a fine choice for a utility distributed as an APK, and it carries a Ko-fi link for donations, which is how the author asks for support. The `AGENTS.md` file at the repository root and the `CHANGELOG.md` suggest a project that is still being worked on actively, with the last push landing days before this review.

Editorial conclusion

Adopt Shappky if you run rooted Android or use Shizuku and want background apps stopped on a schedule, from a Quick Tile, or from Tasker. Skip it if you need something that works on an unmodified device, because the app requires Shizuku or root by definition, and skip it if killing background processes is not something you want automated, since a mistake in a rule can end a process you needed. Before you install, read the documented shell commands in docs/how_shappky_works.md, and set up the protected app list for your keyboard, launcher and core system services first.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. YasserNull/shappky on GitHub