fgkeepalive/AndroidKeepAlive: Persistence Claims and Integration Boundaries

What AndroidKeepAlive Claims to Keep Alive

AndroidKeepAlive addresses a specific Android engineering problem: keeping an application process active after the user leaves its interface, interacts with the system task switcher, restarts the device, or selects the system force-stop action. The intended audience appears to be Android developers researching process persistence, background services, and vendor-specific restrictions. The README also targets people who want the application to reopen an activity from the background and begin working immediately after installation or boot.

The stated feature set extends well beyond a conventional foreground service or one-pixel activity. It includes installation-time autostart, boot autostart, restart within 15 minutes after an unexplained termination, interception of other applications, opening an activity while another application is in use, hiding the launcher icon and application label, and suppressing the uninstall button. Preventing uninstall is described as requiring authorization.

These are repository claims, not measured outcomes in this review. The README includes recordings for a Samsung S21 running Android 13, a Xiaomi 11 running Android 12, and a Google Pixel 6 Pro running Android 12. It does not supply device logs, test procedures, battery measurements, Android 16 test records, or a matrix explaining which behavior requires root, device-owner privileges, vendor access, or a particular APK installation route. A developer therefore cannot determine from the documentation alone which claims apply to an ordinary sideloaded application.

Repository Layout and Native Execution Boundary

Based on the repository layout, the implementation is presented as a mixed native and managed-code project. The root contains `KeepAlive.c`, `KeepAlive.cpp`, `KeepAlive.h`, `KeepAlive.java`, `KeepAlive.js`, and `KeepAlive.py`. The C and C++ files suggest native components, while the Java file fits Android application integration. The presence of JavaScript and Python files does not come with a documented role, entry point, interpreter, or build instruction in the README.

The README attributes the design to Linux characteristics, but it does not name a syscall, daemon topology, Binder path, process relationship, or watchdog process. It mentions Binder in connection with background page opening, but does not explain the calling chain. Consequently, the exact persistence architecture is not visible from the documentation. The source filenames identify possible implementation layers, not how Android components are registered or connected.

An older update dated 2023-08-04 says the core code was moved into a separately encrypted custom Java virtual machine. It also says code obfuscation was strengthened and that packaged structures could be made unique. This description raises an integration concern: engineers need clear API boundaries and build instructions if another application must call the supplied code. The README gives no public SDK interface, Gradle dependency, sample Activity, manifest, ProGuard configuration, or native build command. That omission makes the repository more of an implementation reference or contact-led delivery than a self-contained buildable project.

Obtaining AndroidKeepAlive and Starting a First Evaluation

The repository does not provide installation or build commands. It also says that demo downloads are temporarily closed. The documented route is to request a demo by email at `[email protected]` or through the Telegram contact listed in the README. The project also states that users must explain their purpose and that illegal requests are declined.

A first legitimate evaluation would therefore begin with a written scope from the maintainer. Ask for the demo APK or source build instructions, minimum Android version, required permissions, device-owner or administrator status, and the exact privilege needed for preventing uninstall. None of those details is present in the README, so no safe installation example can be reconstructed from it. Any request for a commercially distributable build should also identify the intended distribution channel because the README makes claims about Google Play availability without documenting a release artifact.

Once a demo is obtained through the stated contact route, inspect its Android manifest before installation. Confirm requested permissions, exported components, foreground services, device-admin receivers, accessibility configuration, boot receivers, notification behavior, and uninstall settings. The README does not document those manifest entries, so this review cannot state what the demo will request. Do not assume that a request for a research build makes hidden activation, icon removal, or uninstall blocking acceptable for an end-user application.

Android 16 Claims and Compatibility Boundaries

The current README says that Android 16 support covers process persistence and background page display, and an update dated 2026-05-18 says it adapts to Android 16 behavior changes and restrictions. It also claims lower-power operation, improved stability, stronger feature concealment, and anti-detection capability. Those statements are not accompanied by technical notes, source references, device results, or measurement procedures.

The recordings shown in the README cover Android 12 and Android 13 devices, not Android 16. The release history mentions earlier work for Android 14, including API changes, crash fixes, vendor compatibility, memory optimization, and low-end-device adjustments. It also mentions specific support work for Xiaomi MIUI 12. This history suggests that vendor and Android-version behavior receives attention, but it does not establish that one mechanism works identically across Android, Samsung, Xiaomi, and Google devices.

The phrase "support Android 16" therefore needs a precise definition. It could mean that the package builds, that an activity can be launched, that boot registration completes, or that persistence continues under tested power-management policies. The README does not distinguish those outcomes. An engineer should require a per-device test matrix before treating the compatibility statement as an adoption criterion.

Failure Modes and Inappropriate AndroidKeepAlive Use Cases

The central limitation is evidentiary rather than cosmetic. A README claim that an application remains alive after force stop or can block uninstall cannot be validated from the repository files and README alone. Android behavior varies by release, vendor image, battery policy, installation method, and application privileges. A method that works on the three recorded devices may fail on an unlisted handset or after a security update.

The project is also wrong for applications that must respect explicit user commands. If a user invokes force stop, expects uninstall to work, or sees an application disappear from the launcher, persistence and concealment conflict with ordinary Android control expectations. The README itself associates some features with hiding the icon and disabling the uninstall button. Those behaviors create acceptance, support, and distribution problems independent of whether the native mechanism functions.

Another limitation is operational opacity. No GitHub releases exist, and there is no published changelog file beyond entries embedded in the README. There is no documented support policy, compatibility matrix, crash-reporting process, or migration procedure for Android API changes. Version continuity would depend on direct maintainer contact and source delivery rather than a documented release channel.

Maintenance, License, and Alternative Architecture

The repository is not archived, and the last push was on 2026-09-11. That is recent maintenance activity, but it does not establish long-term support or the compatibility of every claimed feature. Since GitHub releases are absent, consumers do not receive versioned release notes or downloadable binaries through the repository's release mechanism.

The repository declares the MIT license and includes `LICENSE` and `LICENSE.md`. That designation concerns permission to use, copy, modify, merge, publish, distribute, sublicense, and sell copies, subject to the license text and preservation of its notice. It does not grant permission to impersonate another application, bypass device policy, or evade platform review. This review does not provide legal advice about a particular deployment.

A real alternative is to use Android's documented lifecycle model with a foreground service, appropriate notification, boot receiver, WorkManager scheduling, and device-owner APIs where enterprise use justifies them. This approach does not promise survival after force stop and does not hide the application. Its advantage is that its permissions, lifecycle trade-offs, and user-visible behavior can be documented. AndroidKeepAlive instead focuses on concealment and persistence beyond ordinary controls, but the current repository does not expose enough build or test information to compare either approach at source level.

Editorial conclusion

Adoption is plausible only for authorized Android engineering research after the maintainer supplies a buildable demo and explains each mechanism. It is unsuitable for ordinary production applications, consumer distribution, or any deployment that depends on unverifiable persistence claims. The first verification target should be the missing build and installation path for the C, C++, Java, JavaScript, and Python components.

Frequently asked questions

Official sources

1. fgkeepalive/AndroidKeepAlive on GitHub
2. Issues
3. License: MIT
4. README