SU_IMD: the settings hider that disables rather than conceals

It disables the settings rather than hiding the app

The mechanism is the whole design, and it is stated in one sentence inside the flowchart that explains how the app works. When you open a chosen app, either from the launcher or from a shortcut IMD generated, IMD actually disables those settings, and the claim attached to that step is that no app's security policy is broken. You then use the app as normal. When you are done, you use the Revert function, and IMD re-enables what it switched off. The distinction from the usual category of hiding tools is that nothing is concealed from the operating system. The capability is genuinely off while the target app is open, so the target app's own check sees a disabled setting rather than a missing package. The Revert function is deliberately reachable from five places, a notification, a quick toggle, a Quick settings tile, a homescreen shortcut, or the settings manager, so that a state left switched off is always recoverable.

WRITE_SECURE_SETTINGS is mandatory, and Shizuku is the optional half

The permission section is short and unambiguous. `WRITE_SECURE_SETTINGS` is the mandatory one, granted once through an adb shell command or through Shizuku, and it is described as needed to change settings state. That single grant is what makes a rootless design possible at all, so it is also the thing that will stop the app working on a device you cannot get that grant onto. The Shizuku service is optional and has one specific job, hiding the display-over-other-apps permission, which is an appops permission rather than a normal setting. Post notifications is optional. Everything else is optional and only needed if you use the automations. The platform floor is Android 7.0, meaning API 24, or newer, and the README states plainly that no root is required. In practice that combination, one privileged grant plus a wireless pairing service, is the entire setup cost.

No network permission means no self-update

The security section makes four claims and then draws a consequence from the last one. There is no internet access and no unnecessary continuous background service, which is why the claimed battery and resource cost is near zero. The app does not tamper with any apps on the device. The parts that change settings cannot be triggered by another app, so only you can change them. And there are no ads, analytics, trackers or accounts. The consequence is the interesting part: because the app holds no network permission at all, it cannot check for its own updates, which is why an external updater is how you find out that a new version exists. That is why the README carries badges for Obtainium and for F-Droid, and why the update path is a two-part installation rather than a single download.

Three automation modes and a live settings manager

Alongside manual toggling there is a settings manager that shows the live status of each setting or service and lets you switch them on and off quickly, which is the part that makes the app usable without reading documentation. Three automations sit on top. Auto unhide puts the settings back on a schedule or trigger. Auto hide takes them away again, and that one is marked as requiring a background service and being part of the paid tier, IMD+. And IMD Intents expose the same operations to Tasker and MacroDroid, secured with auth keys rather than being freely callable. That last design choice is the one that keeps the earlier security claim true, since an intent surface is exactly the kind of thing another app could otherwise abuse, and the auth keys are what stop it.

The list of switchable settings is short and per-app configurable

What can actually be toggled is enumerated, and the list is short enough to check against your own threat model. Developer settings. ADB and debugging. Accessibility services. Display over other apps, which needs an active Shizuku service. And the Shizuku service itself, which is the one that lets you turn off the tool you are using to turn off other things. Beyond those five, more can be configured per app through a hiding framework, and the documentation points you at a Settings observer for help finding them. The motivating case is given at the top, restrictive apps such as banking and payment apps, and it is worth being precise about why those apps are the target: they check for developer options and debugging being enabled and refuse to run, so the only way to use them on a device you develop on is to make those checks read false.

A fork with its own package, so both can sit on one phone

SU_IMD is described as a fork of Geto, and the relationship is handled cleanly in one respect that matters for anyone who already uses the original. The package is `com.soul_99.suIMD`, so it installs alongside stock Geto and the two can coexist on the same device rather than forcing a choice or a reinstall. Licensing follows the original, GPL-3.0, and attribution is explicit: the original project is Geto by JackEblan, and there is a separate credit for the initial framework behind the display-over-other-apps work. The naming is slightly untidy, since the repository is called SU_IMD while the application is branded IMD for It's My Device, and the internal documentation file is named SUIMD.md. The tree also carries a separate DejaVu licence file next to the main one, which is the font licence for bundled assets.

SUIMD.md exists because the fork changed things on purpose

There is one instruction in the development section that tells you what the project expects of contributors: before changing anything, read SUIMD.md. That file documents how the app works, how each of its logics runs, and what was changed from the original Geto and why, including the bugs that were found in the original and the reasoning behind each fix. The closing claim is worth repeating, that almost everything which looks odd in this code is answered there. Only after that does it point you at CONTRIBUTING.md before opening a pull request. The repository layout backs the split up, with separate top-level modules for the application, the domain layer, data, features, framework, shared common code, a design system and design assets, a service module, a broadcast receiver module, build logic as an included build, tools, a baseline profile, Fastlane and a Spotless directory.

The author is a resident and says so in the README

Maintenance risk is disclosed rather than left for you to infer. The app was created inside a full-time medical residency schedule, out of the author's own need for it, and shared with the free and open source community after positive feedback. He identifies himself as a radiology resident for whom software is a part-time hobby, warns that replying to queries, fixing bugs and adding features may take time because of the profession, and states that he wants the project taken over by more capable developers since his work does not allow him to maintain it all year round. He does say he plans to maintain it for the near future, until someone else makes a better app for the same purpose. The support requests are correspondingly modest, sharing the project, starring the repository, reporting bugs, joining a subreddit, or contributing code and docs, and sharing is listed as the most helpful of them, with no credit or mention asked for, just this snippet to copy:

https://github.com/soul-99/SU_IMD

Releases moved from v1.6.8 to v2.0 to v3 inside three weeks in late August and early September 2026.

Editorial conclusion

SU_IMD fits someone running a banking or payment app on a device where developer options, debugging or accessibility services trip that app's security checks, and who is willing to grant WRITE_SECURE_SETTINGS once and keep Shizuku running for the display-over-other-apps case. It fits badly if you cannot grant that permission, since there is no rootless alternative to it, and it fits badly if you need the project to still be here in five years. Three things to know before you install. The mechanism is genuinely disable-and-revert rather than concealment, which is why the project claims no app's security policy is broken, and the revert is reachable five different ways so a failed revert does not leave a setting switched off. Updates come from Obtainium or F-Droid, because the app has no network permission at all and therefore cannot tell you a new version exists. And the author states plainly that he is a full-time resident, that replies and fixes may take a while, and that he wants the project handed to someone with more time, which makes the comparison against stock Geto and the SUIMD.md document the two things worth reading before you rely on it. GPL-3.0, released through v3, last pushed on 9 September 2026.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. soul-99/SU_IMD on GitHub