# InstallerX Revived: a replacement Android package installer for Shizuku, Root and Dhizuku users > InstallerX Revived is the community-maintained continuation of InstallerX, a Kotlin Android installer that handles APK, APKS, APKM, XAPK and batch installs through configurable profiles. It is for people who want more control than the stock installer gives them, and it costs you a privileged helper to get there. **wxxsfxyzm/InstallerX-Revived** — More Expressive InstallerX ! - Repository: https://github.com/wxxsfxyzm/InstallerX-Revived - Website: https://wxxsfxyzm.github.io/InstallerX-Revived-Website - Stars: 6,785 · Forks: 247 - Language: Kotlin - License: GPL-3.0 - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/wxxsfxyzm-installerx-revived ## What InstallerX Revived replaces, and for whom Stock package installers on Android are deliberately narrow. They install one APK, or a split set the OEM already knows how to assemble, and they surface very little about what is happening: which user the package targets, whether DexOpt runs, which installer name is recorded, whether a signature mismatch is about to overwrite an existing app. InstallerX Revived exists to put those decisions back in front of the user. The README describes it as "a modern Android package installer and the community-maintained continuation of the original InstallerX project", and the feature list is essentially a list of things the stock installer does not let you configure. The audience follows from that. If you routinely install APKS, APKM or XAPK bundles, or APK files packed inside ZIP archives, or you batch-install several APKs at once, the stock flow forces workarounds. InstallerX Revived handles those formats natively. The second audience is people who already have privilege on their device through Shizuku, Root or Dhizuku and want installation to be silent, scripted or policy-driven rather than tapped through. The third, smaller audience is ROM tinkerers who want to lock a third-party installer as the system default or replace the system package manager outright. The README notes that replacement is for advanced users, which is the right framing: it is not a first step. ## Authorizers are the core mechanism, not a settings detail The architecture is easiest to understand as two layers. The upper layer is the UI and the profile engine; the lower layer is the authorizer, which is whatever actually holds the privilege to install. InstallerX Revived supports four: Root, Shizuku, Dhizuku and None. They are not interchangeable, and the README is unusually direct about the differences. Root "can perform all privileged operations, but may be slower because of cold app_process startup". Shizuku "obtains shell or root capabilities depending on how it is activated, and is usually faster than direct Root". Dhizuku "can perform DevicePolicyManager-based operations such as default installer locking and app installation, but is limited for other privileged tasks". None is "fully limited by the system, but can silently install when InstallerX is running as the system package installer". That last clause is the interesting one: the None path is not useless, it is just conditional on InstallerX already occupying the system installer role, which is a chicken-and-egg problem on ROMs that fight you over that role. Profiles sit on top of the authorizer. A profile defines "install mode, authorizer override, installer/requester metadata, target user, DexOpt, auto-delete behavior, split selection, blacklist policy, and signature gates". The authorizer override is what makes profiles useful: you can route a specific app or a specific source through a different privilege path than the global default. If your global authorizer is Shizuku but one package needs a DevicePolicyManager operation, a profile can send it to Dhizuku instead. ## Installing InstallerX Revived and running a first install The project ships as an Android application, not a library, so there is no package manager step. The README points to three download channels: stable releases at the GitHub releases/latest URL, alpha builds at the wxxsfxyzm/InstallerX releases page, and CI builds from the auto-preview-dev workflow. It also notes that InstallerX "is now published as a single APK", that network access is controlled by an in-app setting, and that the `online` token in the release filename is kept only for compatibility with older in-app update clients rather than identifying a separate build variant. That last point matters because the related searches show people asking about "online vs offline" builds; per the README there is no longer a functional split. Install the APK, open it, and set up an authorizer before doing anything else. If you use Shizuku, start the Shizuku service through your usual method (the README does not document the Shizuku bootstrap itself, only that InstallerX consumes it) and grant InstallerX access. Then open an APK or XAPK from your file manager and choose InstallerX as the handler. If you would rather build it yourself, the repository is an Android Gradle project and the README gives the prerequisites plainly. JDK 25 with `JAVA_HOME` set, the Android SDK with the required platform and build tools, and GitHub Packages credentials for the snapshot `miuix` dependency. GitHub Packages requires authentication even for public packages, so you add a classic personal access token with the `read:packages` scope to your global Gradle properties file: ```properties gpr.user=YOUR_GITHUB_USERNAME gpr.key=YOUR_PERSONAL_ACCESS_TOKEN ``` The README warns not to commit those credentials to the repository. With that in place, a local debug build is a single command: ```bash ./gradlew assembleUnstableDebug ``` For a test build that installs alongside the normal app instead of overwriting it, the README gives a separate application id through a Gradle property: ```bash ./gradlew assemblePreviewDebug -PAPP_ID="com.rosan.installer.x.revived.test" ``` That preview variant is the one worth using if you intend to keep a stable install for daily use while experimenting with CI builds, since the separate application id keeps the two from colliding. ## Where the privilege model breaks down The clearest limitation is that InstallerX Revived cannot grant itself the authority it needs. Every silent-install path depends on an authorizer the user has already set up, and the README's own troubleshooting entries are admissions of this. The default-installer lock is the first failure mode: "Some OEM systems strictly control the default package installer." The suggested workaround is to open the default installer page from the Home page status card and try locking from there, and if the ROM still refuses, to use an LSPosed module such as InxLocker. That is a real dependency on a third-party module outside this repository. The second is HyperOS. The README states that HyperOS reports "installing system apps requires a valid installer", that this is an OEM security restriction, and that InstallerX declares installer metadata through profiles and uses `com.android.shell` as the default compatibility installer package on HyperOS. Crucially, "Shizuku or Root is required for this workflow; Dhizuku is not enough". So a Dhizuku-only user on HyperOS hits a wall that no profile setting removes. The third limitation is version support. Full support is Android SDK 34 to 37.0; SDK 26 to 33 is described as limited, meaning "InstallerX may work, but some features can be unavailable or behave differently because of Android framework, OEM, or authorizer limitations". If you are on an older device, you are in the degraded tier by design. Finally, the release cadence is worth reading carefully. The most recent release listed is a preview build dated 2026-09-16, while the stable release 26.05.01 is dated 2026-05-30. The README itself says that when reporting bugs you should reproduce on the latest Alpha or CI build "because issues in Stable may already be fixed". That is a project telling you the stable channel lags behind the fixes. ## How it differs from InxLocker and from the stock installer The natural comparison inside this ecosystem is InxLocker, and the README makes the boundary explicit rather than treating it as a rival. InxLocker is an LSPosed module, which means it hooks the system at the framework level and requires LSPosed to be installed and active. InstallerX Revived is a standalone app whose privileged work goes through Shizuku, Root, Dhizuku or the system package manager role. The difference in approach is where the privilege lives: InxLocker changes system behaviour from inside, while InstallerX Revived asks an external privilege broker for permission each time it acts. That gives them different failure profiles. An LSPosed module stops working when the hook target changes or when the framework update breaks the hook, and it does nothing on a device without LSPosed. InstallerX Revived works on any device where you can run one of its authorizers, but it is subject to whatever the OEM decides about third-party installers, as the HyperOS notes show. The README actually suggests using them together: InxLocker is the recommended fallback when the ROM blocks the default-installer lock. So the honest framing is not "pick one" but "InstallerX Revived is the installer, InxLocker is one of the levers you may need to make it the default". Against the stock installer, the difference is scope rather than privilege. The stock installer is the reference implementation of what the platform permits; InstallerX Revived is a configurable front end that adds format support (APKS, APKM, XAPK, APKs in ZIP, batch), profile-driven metadata and policy, and a choice of privilege backends. If you never touch any of those, the stock installer is simpler and has no authorizer to keep alive. ## Licence, build cost and what upgrading involves InstallerX Revived is GPL-3.0. For an end user installing the APK, that mostly means the source is available and modifications you distribute must carry the same licence. If you fork it, ship a modified build, or embed it in a ROM, the copyleft terms apply to the distributed work, and the README's instruction not to commit `gpr.user` and `gpr.key` into the repository is a separate operational concern rather than a licence one. This is not legal advice; read the GPL-3.0 text if you plan to redistribute. The build cost is not trivial for an Android app. JDK 25 is a recent requirement, and the `miuix` snapshot dependency sits behind GitHub Packages authentication, so a clean clone does not build until you create a classic token with `read:packages` and put it in `~/.gradle/gradle.properties` on Linux or macOS, or `%USERPROFILE%\.gradle\gradle.properties` on Windows. That is friction that a typical F-Droid-style project does not have, and it also means the build depends on GitHub's package registry staying reachable and on the snapshot artifact continuing to exist. Upgrade cost for users is low by design: the app updates itself through the in-app update client, which is why the release filename still carries the `online` token. The maintenance signal is the last push on 2026-09-20 and a preview release on 2026-09-16, so the repository is being worked on. The stable channel, at 26.05.01 from 2026-05-30, is roughly four months behind the preview. If you want fixes as they land, you are choosing the alpha or CI channel and accepting preview-build risk. The README's own bug-reporting guidance pushes you that way. ## Conclusion Adopt InstallerX Revived if you already run Shizuku, Root or Dhizuku and you install split packages, XAPK or APKM files often enough that the stock installer's limits annoy you. Skip it if you only sideload the occasional single APK, or if you are unwilling to keep a privileged helper running, because the authorizer is what makes the profile features useful rather than decorative. Before committing, verify that your Android version is in the full-support range of SDK 34 to 37.0, that your OEM allows the default-installer lock from the Home page status card, and that you can build the project at all: it needs JDK 25 plus a GitHub classic token with read:packages for the miuix snapshot dependency. ## FAQ ### What is InstallerX Revived? It is a modern Android package installer and the community-maintained continuation of the original InstallerX project, licensed GPL-3.0. It replaces the stock or OEM installer with a configurable one that supports APK, APKS, APKM, XAPK and batch installation, and can perform privileged installs through Shizuku, Root, Dhizuku or the system package manager mode. ### How do I install InstallerX Revived? Download the APK from the stable releases page, the alpha builds page, or the CI workflow, then install it like any other Android app. The README notes it is published as a single APK and that network access is controlled by an in-app setting. ### How do I use InstallerX Revived? Set up an authorizer first, such as Shizuku, Root or Dhizuku, then open a package with InstallerX. Profiles control how each install is handled, including install mode, authorizer override, target user, DexOpt, split selection, blacklist policy and signature gates. ### Is there an alternative to InstallerX Revived? InxLocker is the alternative the README itself names, but it is not a like-for-like replacement: it is an LSPosed module rather than an installer app. The README recommends it as a fallback when an OEM ROM blocks locking InstallerX as the default installer. ### Can I uninstall the package installer? The README does not document uninstalling the system package installer. It does describe installing InstallerX Revived as a replacement system package manager, and says that route is for advanced users. ## Sources - [License: GPL-3.0](https://github.com/wxxsfxyzm/InstallerX-Revived/blob/main/LICENSE) - [Project website](https://wxxsfxyzm.github.io/InstallerX-Revived-Website) - [README](https://github.com/wxxsfxyzm/InstallerX-Revived/blob/main/README.md) - [Releases](https://github.com/wxxsfxyzm/InstallerX-Revived/releases) - [wxxsfxyzm/InstallerX-Revived on GitHub](https://github.com/wxxsfxyzm/InstallerX-Revived) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wxxsfxyzm-installerx-revived