KeepAlivePerfect: five strategies to keep an Android process alive

Process resurrection, and two ways to reach the system

KeepAlivePerfect is an Android application keep alive library that implements process resurrection through JNI and communication with the Binder framework, and then goes further by using `ioctl` to raise the resurrection rate, maximising application persistence. The library is offered for Android 4.1 through Android 16 according to the repository description, and the README narrows the supported range to Android 7.0 to Android 16, that is API 24 to 36. The interesting mechanism is the split into two branches, because the repository contains both. The `main` branch is the version that uses `libbinder.so` to communicate with the ActivityManagerService, and the `ioctl` branch uses `ioctl` to talk to the binder driver directly, with a higher resurrection rate. That is an unusual level of access for an application library, and it explains the design choices that follow, since a process that has been killed has to be brought back by something outside the normal app lifecycle. The README also points at a companion repository, KeepLiveService, described as the complete code repository for the project.

Five strategies, layered, with the reasoning written down

The architecture diagram in the README shows a facade entry point, KeepLive, whose `startWork()` initialises every keep alive strategy, and underneath it five parallel mechanisms with a LocalService in the main process and a RemoteService in a `:remote` guard process. The design decision table explains why each one is there. A dual process AIDL binding with the `BIND_ABOVE_CLIENT` flag means that when one process is killed the other immediately revives it, with the highest priority binding. A silent music loop keeps the CPU awake and prevents deep sleep. A one pixel Activity, a transparent 1x1 Activity raised when the screen is off, raises the process priority. A JobScheduler with a 30 second period acts as a system level timer that periodically checks and restarts services that have died. And there are two run modes, ENERGY, which is power saving with delayed playback, and ROGUE, which is aggressive with immediate playback. The point of the layering is redundancy. Any one of these can be defeated by a vendor's process policy, and the library is betting that five independent mechanisms will not all fail at once.

The startup flow, and what the two processes do

The core flow list in the README describes the sequence precisely. The application starts in `attachBaseContext()`, calls `KeepLive.startWork()`, and on API 21 and above the JobHandlerService is started first, whose `onStartCommand()` schedules the JobScheduler with its 30 second period, starts the LocalService and starts the RemoteService, while below API 21 the two services are started directly. The LocalService's `onStartCommand()` then creates the foreground notification, starts the silent music loop, registers a screen state listener, binds the RemoteService with `BIND_ABOVE_CLIENT`, and finally calls back `KeepLiveService.onWorking()`. The RemoteService in turn binds back to the LocalService with the same flag. That mutual binding is the heart of the design, since the two processes watch each other, and the `BIND_ABOVE_CLIENT` flag is what makes the survivor's binding outrank the platform's own service management. The service classes are split accordingly, with LocalService, RemoteService, JobHandlerService marked as API 21 and above, and a HideForegroundService in the same package.

The API, the run modes and the callback contract

Integration is meant to be one call. The library exposes a `KeepLive.startWork()` entry point that takes the context, a run mode, a foreground notification description and an implementation of the `KeepLiveService` callback interface.

        // 启动保活服务
        KeepLive.startWork(
            this,
            KeepLive.RunMode.ENERGY,        // ENERGY（省电）或 ROGUE（激进）
            foregroundNotification,
            object : KeepLiveService {
                override fun onWorking() {
                    // 保活服务启动时的业务逻辑（如 socket 连接、心跳检测）
                    // 注意：此方法可能被多次调用
                }

                override fun onStop() {
                    // 保活服务停止时的清理逻辑
                }
            }
        )

The callback contract is the part that will bite you if you miss it, because the comments in the example warn that `onWorking` may be called multiple times, and the same note appears on `onStop`, so the two are meant to be paired and your logic has to be idempotent. The foreground notification is built through the `ForegroundNotification` constructor with a title, a description and a small icon, and the click handler is passed as a lambda. The two run modes differ only in timing, with ENERGY delaying the silent music by five seconds after the screen turns off and ROGUE starting it immediately.

Manifest, Gradle and the demo application

The library ships as a Gradle module named `library` under the package `com.fanjun.keeplive`, and the demo application module is `app` under `com.boolbird.keepalive.demo`. To use it in your own project you add the module to `settings.gradle` and depend on it from your app's build file, and the README gives both lines. The manifest side is short, because the library's own manifest declares every service, receiver and activity it needs and those declarations are merged at build time, so the application only has to declare the two permissions, `FOREGROUND_SERVICE` and `REQUEST_IGNORE_BATTERY_OPTIMIZATIONS`, and point the application element at your own Application class. The environment is pinned tightly, with Kotlin 2.3.10, Android Gradle Plugin 9.0.1, Gradle 9.3.1, JDK 17 or later, `compileSdk` and `targetSdk` of 36 and a `minSdk` of 24, plus Android Studio Ladybug or later. The build itself is the standard Gradle wrapper set, assembling a debug or a release build, cleaning, and running lint.

How to check it works, and where it does not

The README gives a verification command, which is the kind of detail that separates a serious library from a hopeful one, since the only way to know a keep alive mechanism works is to look at the process list.

adb shell ps | grep your.package.name

If you see the main process and the `:remote` guard process present at the same time, the keep alive is working. The repository also contains a `kill_alive.sh` script, which is the natural companion to that check, since the only convincing test of a resurrection mechanism is killing the process and watching it come back. The honest limits are stated in the same section that lists what the library does not do. It does not guarantee 100 percent effectiveness on all domestic ROMs, because each vendor has its own background management policy, and it is not recommended for consumer facing products because it may cost users performance. Where it does not work, the guidance is to walk the user through adding the app to the battery optimisation whitelist, allowing auto-start, and locking the app in the recent tasks list. The `ioctl` branch is described as the one with the higher resurrection rate, which is the branch to try first if the default is not enough.

Project shape, licence and where the rest of the code lives

The repository is a Gradle Kotlin project with the `app` and `library` modules, a root `build.gradle.kts`, `settings.gradle.kts`, `gradle.properties` and the Gradle wrapper, plus a `CONTRIBUTING.md` and a `LICENSE` file. Inside the library module the structure mirrors the design, with an `aidl` directory holding the `GuardAidl.aidl` IPC interface, a `config` package with `ForegroundNotification`, the `KeepLiveService` business callback interface and `NotificationUtils`, a `service` package with the four service classes, an `activity` package with `OnePixelActivity`, a `receiver` package for broadcast receivers and a `utils` package with `ServiceUtils` for service state detection. The silent music is not a generated tone but a resource, a `novioce.wav` in `res/raw`. The licence is MIT, the last push was on 2026-09-17, and the repository publishes no GitHub releases, so there is no version history to consult, and the README points at the separate KeepLiveService repository for the complete code, which is worth a look before you try to work out which parts of the mechanism live where.

Editorial conclusion

Adopt KeepAlivePerfect if you are building an Android app that must survive aggressive vendor process management, for example a long running background service on a Chinese ROM, and you control the device or can ask the user for a battery optimisation exemption. Do not adopt it for consumer facing products, because the README explicitly advises against it on the grounds that it can cost users performance, and it does not guarantee effectiveness on all domestic ROMs. Before you rely on it, test on the actual vendor builds you target, since the README asks you to guide users to whitelist the app, allow auto-start and lock the app in the recents list. Also read the two branches, because the `ioctl` branch is the one the author considers more aggressive, and check the API level floor of 24, meaning Android 7.0. The licence is MIT, the last push was on 2026-09-17, and the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Pangu-Immortal/KeepAlivePerfect on GitHub
4. README