Inure edits installed APKs in place through root or Shizuku

The package manager treats an APK as an editable document

The About section makes the unusual claim first: Inure is an Android application package manager "irrespective of whether they're installed or not", and it "can scan through any app's internal components and modify them on the go."

That is a different contract from a launcher-side debloat tool. A conventional app manager lists what is installed and lets you uninstall, freeze or clear data. Inure opens the package itself, so the work happens inside the APK rather than beside it, and it does not require the app to be installed for you to look at it.

Around that core sit the tools the README names: a Terminal Emulator, Usage Stats, and a Split/APK Installer. The phrasing about many of them "waiting to be implemented as well" is worth reading carefully, because it tells you the tool list in the README is not a promise of parity between features.

The feature inventory is not in the README at all. It points at `FEATURES.md` for a "concise list of features of the app", so the README itself gives you the headline and defers the detail to a separate file.

The app is written in Kotlin, with `app/` holding the module alongside `community/` and `stub/`, and a Gradle project at the root including `gradlew`, `build.gradle`, `settings.gradle` and `gradle.properties`.

Root and Shizuku are both first-class, not a fallback

The privilege model is the design decision behind everything else. The README says that "all functionalities been made to work with both Root and Shizuku modes", and the repository topics list both `root` and `shizuku` alongside `terminal` and `mvvm`.

Root means the app can do what it likes on a device you have unlocked. Shizuku is the weaker path that keeps the actual privilege out of the app process, so it survives on a stock device with wireless debugging or an app that has granted it once. Supporting both means the same feature set works whether you have Magisk or you have never rooted anything.

That matters more here than in an ordinary Android utility. If modifying an APK requires writing outside the app sandbox, then a tool that only supports root excludes most users, and a tool that only supports Shizuku excludes rooted purists who would rather not hand out root. The README does not describe which specific operations need which path, so that mapping is something you would have to check on a device.

The minimum SDK is 23, Marshmallow, and the target SDK is 35, which the badges spell out. A minimum that old is the reason the built-in terminal emulator is plausible at all: the app targets devices old enough that many useful shell utilities are still relevant there.

The UI is hand-built, and the theme engine is part of the project

The About section describes the presentation layer as a deliberate choice rather than an accident. It calls the app "based 100% on custom UI APIs developed to be used only in this app with its own native theme engine, crash handler, image renderer and a beautiful animation framework".

The repository description repeats the same claim: "purely custom UI design and reproducible build". So four custom systems ship instead of Material Components, and each one is something a contributor has to learn before touching the UI.

The counterweight is Material You. The README states that Inure also supports dynamic Material You colors with dedicated accent and theme color modes, so a user on a recent Android release gets wallpaper-derived colours while the custom layer handles layout and motion.

Distribution follows the same pattern. The app is on the Play Store under a play-specific package id, on F-Droid under the main package id, on IzzyOnDroid, and mirrored on SourceForge, with GitHub releases as a fourth path. That spread matters for a tool that asks for elevated privileges: a user verifying what they are installing has several places to compare the artifact.

Localisation runs through Crowdin, indicated by the badge and a `crowdin.yml` at the repository root.

Full version is a separate key or unlocker app, bought five ways

The monetisation is unusual enough to describe precisely, because it changes what you install. The README separates the free download from a "Buy (Full Version)" section that lists four purchase routes: a Licence Key through GumRoad, a Full Unlocker app on the Play Store, a Full Unlocker tier through GitHub Sponsors, and a Full Unlocker through Ko-fi.

So the free build is not a trial that expires, and the paid part is not a subscription. You either run the free build with its limits, or you acquire a key or the unlocker and install or apply that. For a privacy-sensitive tool, that is a relevant detail: the unlocker is a separate application, and the Play Store listing has its own package id.

The version scheme in the release tags follows the same shape, with `build107.2.4` from 2026-10-03, `build107.2.3` from 2026-09-19 and `build107.2.2` from 2026-09-03. A build number followed by a dotted version is what a single developer iterating fast tends to produce, and it tells you the app is versioned per build rather than on a release cadence.

There is also a `requirements.txt` in the repository root pinning pip, wheel, requests and beautifulsoup4 at specific versions, which belongs to the repository's own tooling rather than to the Android build.

Reproducible builds are asserted, and there is a scripts directory to check

The README states that "Inure also supports fully reproducible builds". For an app distributed through five channels and holding elevated privileges, that is a load-bearing claim rather than a nice-to-have: it is what lets someone else confirm that the APK they downloaded matches the source they can read.

The repository gives you somewhere to verify it. There is a `scripts/` directory, a `.gitattributes`, a `.idea/` directory, `assets/`, `community/`, `fastlane/` and `stub/` alongside the Gradle project, and `changelogs.md` at the root.

Two caveats on reading the README. First, it says the app "is in stable testing stage", which is the maintainer's own phrase for a not-yet-settled release, so expect behaviour to change between builds. Second, the README does not describe how the reproducible build is invoked, what toolchain it pins, or how to compare artifacts, so the claim is checkable in principle and unspecified in practice.

Maintenance is current. The repository is not archived and its last push was on 2026-10-13, ten days after the build107.2.4 tag and days after the most recent of the media mentions listed in the Featured section, which are dated 2023.

The licence is GPL-3.0, and there are `SECURITY.md`, `PRIVACY.md` and `CODE_OF_CONDUCT.md` files alongside the README.

How this differs from a desktop APK editor

The realistic alternative for editing an APK is to pull it off the device and work on a computer with apktool or aapt, edit the smali or resources there, sign it, and push it back. That approach has better tooling, better documentation and better reproducibility, and it works on any device regardless of privileges.

The difference in approach is where the work happens. Desktop editing is inspectable: you have the archive, the decoded resources and a signing key you control, and every change is a diff. On-device editing is immediate and works against an installed app without a round trip, which is why it exists at all. What it costs is that the modification happens inside a package manager UI rather than in files you can diff, and the recovery path when you break an app is reinstalling it.

The other comparison is with system-level managers such as a launcher that hides and freezes apps. Those change what runs; Inure changes what is inside a package. For reclaiming space by removing bundled apps, the lighter tool is less risky.

The GPL-3.0 licence is worth noting for anyone considering reuse, since it is the copyleft licence and the README does not discuss relicensing of forks.

Editorial conclusion

Use Inure if you want to inspect what is inside an installed APK and change it without pulling it to a desktop, since that loop is what the root and Shizuku paths exist for. Do not use it as a bulk debloat tool driven by a list you paste, and think twice before running it as your only package manager. Before installing, decide which privilege path you will use, because every feature depends on root or Shizuku and the README does not document how the app behaves when neither is present.

Frequently asked questions

Official sources

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