AlwaysStrong: a one-flash Magisk, KernelSU and APatch module for STRONG Play Integrity
Always Strong: Strong Play Integrity in one drop in module TEESimulator-RS + PlayIntegrityFork bundled.
At a glance
- What is it?
- AlwaysStrong bundles TEESimulator-RS and PlayIntegrityFork into a single root module so you do not have to stack them yourself. It solves the wiring problem, not the cat-and-mouse problem, and the README is upfront about which build to flash and which devices it will not help.
- Who is it for?
- Adopt AlwaysStrong if you already run Magisk, KernelSU, SukiSU Ultra or APatch with a Zygisk implementation and you want STRONG Play Integrity without manually wiring TEESimulator-RS to a Play Integrity fork. Do not adopt it if you are on stock Android without root, if you want a long-term stable target, or if you are unwilling to reflash when the automated keybox stops working.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What AlwaysStrong actually bundles, and who it is for
Play Integrity's STRONG verdict normally requires two separate pieces of work on a rooted device. One piece is a keystore side that answers hardware-backed attestation, which is what TEESimulator-RS provides. The other is a fingerprint side that makes the device look like a Google-signed Pixel running a recent security patch, which is what PlayIntegrityFork provides. Getting both installed, ordered and kept in sync is the part people get wrong.
AlwaysStrong's stated purpose is to collapse that into one zip. The README describes it as "One-flash STRONG Play Integrity for Magisk / KernelSU / APatch" and says it bundles TEESimulator-RS and PlayIntegrityFork "into a single module so you don't have to stack and wire them up yourself." The audience is narrow and specific: people who already run a root manager, already have a Zygisk implementation, and want a single artifact to flash instead of a stack of modules they maintain by hand.
The requirements are explicit. You need Magisk with Zygisk enabled (the README recommends a standalone Zygisk Next, ReZygisk or NeoZygisk over Magisk's built-in Zygisk, which it says is more easily detected), or KernelSU or SukiSU Ultra with one of those Zygisk modules, or APatch with one of them. Android 10, SDK 29, is the floor. If you are not rooted, or you are rooted but have no Zygisk layer, this module has nothing to attach to.
How the keystore, fingerprint and target list fit together
Three mechanisms do the work, and the README describes each.
The keystore half runs TEESimulator-RS. On the first tap of the module's Action button, AlwaysStrong fetches a working keybox and a fresh Pixel fingerprint and restarts Play Integrity. That is the manual keybox step removed: you do not go find a keybox file and place it yourself.
The fingerprint half is the Play Integrity fork. Every Action pulls a fresh Pixel fingerprint and matching security patch, and a background service repeats the pull every hour. The interval is configurable, and the README says each toggle is exposed in the built-in WebUI on KernelSU and APatch. The hourly service also re-checks the keybox and swaps it in only when a newer one is available, so a good keybox is not overwritten by an identical one.
The third mechanism is the attestation target list. A native watcher follows package changes through inotify, so installing a new app adds it to the target list without you editing anything. LSPosed and Xposed managers are deliberately kept out of that list, because attesting through a hooked process breaks STRONG. That is a design decision worth noting: the module is willing to exclude a whole category of packages to protect the verdict.
Installing AlwaysStrong and getting a first verdict
The README gives five steps. Install a Zygisk implementation first, then download the latest ZIP from Releases, flash it in your root manager, reboot, open the module and tap Action.
The download step is where most people should slow down. Every release ships three zips that differ only in how the Pixel fingerprint is spoofed. The README says plainly: if you are not sure, take the plain `AlwaysStrong-<version>.zip` with no suffix. It passes STRONG on most devices. The README names the three downloads as `AlwaysStrong-<ver>.zip` (default, PlayIntegrityFork), `AlwaysStrong-<ver>-inject.zip` (PlayIntegrityFix, inject-s) and `AlwaysStrong-<ver>-nopif.zip` (Lite, no fingerprint spoof).
Flash exactly one. The README states that switching builds means flashing the other zip over the top, and that installing more than one at a time is not supported. The installer also disables a list of conflicting modules at install time and on every boot: TrickyStore, PlayIntegrityFix/Fork, TEESimulator, playcurl and playcurlNEXT, SafetyNet Fix, MagiskHidePropsConf, Tricky Addon, Yurikey, and a few others. If any of those are load-bearing for something else on your device, know that before you reboot.
After the reboot, open the module and tap Action. The first tap is the one that fetches the keybox and fingerprint. Then check the verdict with a checker the README names: Play Integrity API Checker, YASNAC, or Simple PIC. There is no command-line step and no config file to edit for the basic path; the WebUI on KernelSU and APatch is where the hourly toggles live.
The -nopif build, and when AlwaysStrong is the wrong tool
The Lite build is the honest part of this project. If the bundled fingerprint spoof conflicts with Google Play Services, the symptoms the README lists are Play Store crashes, a "couldn't load" account screen, and missing-dependency errors. In that case `AlwaysStrong-<ver>-nopif.zip` keeps hardware attestation and the automated keybox but performs no fingerprint spoof at all. You bring your own PlayIntegrityFork or PlayIntegrityFix, and the README says the module detects it and keeps it in sync.
That is a real limitation stated as one. A module that promises STRONG and then ships a variant with no fingerprint spoof is admitting the spoof is the fragile half.
There is a second limitation in the ABI table. Every build installs on arm64-v8a, armeabi-v7a, x86 and x86_64, but PlayIntegrityFix inject-s has no x86 zygisk. On x86 or x86_64 the `-inject` build cannot spoof Play Integrity, and the README says the installer tells you so. On x86 you are pushed to the default or the Lite build.
The case where AlwaysStrong is the wrong tool is broader than either of those. It is a root module. It does nothing on an unrooted device, and it depends on a Zygisk implementation that itself has to survive detection. If your threat model includes an app that fingerprints the root environment rather than querying the Play Integrity API, this module does not address that. It also assumes you accept an automated, server-fetched keybox. The README does not document what happens if that fetch fails, and it does not document rollback.
TrickyStoreOSS and TEESimulator as alternative keystore engines
The keystore half is swappable. The README documents two optional engines: TrickyStoreOSS, selected with the `-TSOSS` suffix, and the original TEESimulator by JingMatrix, selected with `-TEESIM`. They combine with all three fingerprint lines, giving `-TSOSS`, `-inject-TSOSS`, `-nopif-TSOSS`, `-TEESIM`, `-inject-TEESIM` and `-nopif-TEESIM`.
The difference from the default is not in approach but in packaging and support. These variants are nightly-only and never appear in a release. You download the latest nightly from the nightly.link table in `docs/ADVANCED.md`, one artifact per variant, or build them yourself with the flags the README gives: `./build.sh --engine trickystoreoss` or `./build.sh --engine teesim`.
They do not auto-update, which is the sharpest trade-off in the whole project. The default builds update themselves in place through your root manager; the alternate engines leave that to you. The README also notes that `-TEESIM` is 64-bit only, and points to `docs/ADVANCED.md` for caveats, in particular Lite combined with `-TEESIM`.
If you want the automated path, stay on TEESimulator-RS and the release zips. If you specifically want an open-source keystore component or the original TEESimulator, you are opting into manual nightly tracking.
Maintenance, updates and the GPL-3.0 licence
The repository is not archived, and the last push was on 2026-09-11. Releases are frequent: v1.0.2 on 2026-07-14, v1.0.3 on 2026-08-06, v1.0.4 on 2026-09-06. The cadence suggests the project is being worked on, but the README does not publish a support window or a compatibility guarantee for any given Android security patch level.
Upgrade cost is low on the default builds because they update in place through your root manager, and the hourly service refreshes the fingerprint and keybox without your involvement. The cost is not zero: an update can change which conflicting modules get disabled, and the README says conflict resolution runs on every boot, not only at install. The alternate `-TSOSS` and `-TEESIM` engines do not auto-update, so every security patch you care about is a manual download or a local build.
The project is GPL-3.0. If you redistribute a modified zip, the licence's source-availability terms apply to what you ship. If you only flash it on your own phone, that is the ordinary use case the README describes. This is a description of the licence identifier, not legal advice.
The README offers support through Telegram: a channel at t.me/keyboxstrong, a root community at t.me/evokeroot, and a chat group at t.me/keyboxstrongchat. There is no documented issue-triage process in the README itself.
Editorial conclusion
Adopt AlwaysStrong if you already run Magisk, KernelSU, SukiSU Ultra or APatch with a Zygisk implementation and you want STRONG Play Integrity without manually wiring TEESimulator-RS to a Play Integrity fork. Do not adopt it if you are on stock Android without root, if you want a long-term stable target, or if you are unwilling to reflash when the automated keybox stops working. Before flashing, confirm your Android version is 10 or higher, decide between the default, -inject and -nopif zips, and check whether any of the conflicting modules the installer disables are load-bearing for you. The installer removes TrickyStore, PlayIntegrityFix/Fork, TEESimulator, playcurl and SafetyNet Fix at install time, so anything you depend on there will be gone after the reboot.
Frequently asked questions
Which AlwaysStrong zip should I download if I am not sure?
The README says to download `AlwaysStrong-<version>.zip`, the plain one with no suffix. It calls that the default and says it passes STRONG on most devices.
What happens the first time I tap Action in AlwaysStrong?
The README states that the first Action tap fetches a working keybox and a fresh Pixel fingerprint and restarts Play Integrity, so there is no manual keybox step.
Does AlwaysStrong work on x86 or x86_64 devices?
Every build installs on arm64-v8a, armeabi-v7a, x86 and x86_64, but the README says PlayIntegrityFix inject-s has no x86 zygisk, so the `-inject` build cannot spoof Play Integrity on x86 or x86_64. On x86 the README points you to the default or the Lite build.
What do I need installed before flashing the AlwaysStrong Magisk module?
The README requires Magisk with Zygisk enabled, or KernelSU or SukiSU Ultra with a Zygisk module, or APatch with a Zygisk module. Android 10 (SDK 29) or higher is required.
Can I install more than one AlwaysStrong build at the same time?
No. The README says to install only one at a time and that switching builds means flashing the other zip over the top.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/evoker0-alwaysstrong)