Geto: an Android app for writing device settings

One idea, taken from an annoyance

Geto applies device settings to your apps. The project description is three words long, and the About section explains why it exists in the author's own words.

The only reason the author created this app is to turn off that damn Developer Options when using a banking app. The annoying part is that you have to go to the Settings app to do it. And when you turn off that switch button, your Developer Options configurations are reset to default.

That last sentence is the actual problem. On many devices, a banking app or a DRM check will refuse to run with Developer Options enabled, and the fix is to disable it, but disabling it wipes the rest of the developer settings you had configured, which means going back to the Settings app again to restore them.

Geto is the answer to that loop. The good thing, in the author's phrasing, is that when you modify your settings through its Shared Preferences, you will not lose all your settings once the Developer Options is modified. The app writes the Settings values, and because the write goes through Shared Preferences rather than through the Settings UI, the values you did not touch survive.

That is a small problem, and the app is a small answer to it, and the README says so plainly rather than dressing it up as a device management tool.

The permission is the whole mechanism

So basically, you have to grant this app with android.permission.WRITE_SECURE_SETTINGS in order for it to modify your Settings values.

That is the technical core of the project, and it is worth being precise about what it means. The Settings provider is a system service, and the values in it are not writable by an ordinary application. The permission that allows the write is one that is normally reserved for system images and for privileged or user-installed applications granted by an administrator, which is why the app needs an extra step from you.

The README's important callout points at a tutorial on YouTube for exactly this, and that is the correct instruction to give, because the procedure for granting the permission differs by device, by Android version and by whether the device is rooted. A user who has never done it before will not find the steps in a text file.

What the app does with the permission is the part it takes from the system rather than inventing: it writes values into the Settings provider, and it does so in a way that does not clobber the values you did not change. Everything else in the project, the interface, the build and the modules, is ordinary Android work.

For a user, the practical checklist is short. Install the app, grant the permission as the tutorial shows, and the app can then set the values that Developer Options normally resets.

The repository is a layered Android project

The top-level directories show a modern multi-module Android application, and the module names follow the conventional layering that the Android community settled on a few years ago.

The app/ directory is the application module, and it holds the launcher icon the README displays. The feature/ directory is where the screens and the ViewModels live, and the ui/ directory holds the design-system/ and the Compose components. The domain/ directory is the business logic, data/ is the persistence layer, common/ is the shared utilities, framework/ is the framework plumbing, and service/ is the background work.

Two module names tell you something specific. broadcast-receiver/ is a separate module, which means the app listens for system broadcasts, which is the mechanism by which it notices that a setting you care about has changed or that a package was installed. And build-logic/ holds the convention plugins, the shared Gradle configuration that every module applies, which is what keeps a project with this many modules buildable.

The build is Kotlin DSL, with build.gradle.kts and settings.gradle.kts at the root and gradle.properties alongside the Gradle wrapper, gradlew and gradlew.bat. The spotless/ directory holds the formatting configuration, and compose_compiler_config.conf is the Compose compiler configuration file, which confirms the UI is Jetpack Compose rather than the older view system.

The .run/ directory holds the IntelliJ run configurations, and .idea/ holds the project settings, both of which are the kind of file a developer keeps in the repository so that a new clone behaves like the machine it was written on.

Distribution, and the fastlane metadata

The app is on F-Droid under the package name com.android.geto, and the README carries the F-Droid badge as well as the F-Droid version badge.

The fastlane/ directory at the repository root is where the store metadata lives, and it is more than a marketing convenience. The screenshots the README embeds are the phone screenshots in the fastlane metadata directory, in the en-US image set, which means the images in the readme and the listing in the store come from the same place and are updated together.

The other badges at the top of the README are the GitHub release version, the licence and the download count. The release badge points at the JackEblan/Geto repository rather than the one you are reading, which is a leftover from the project's earlier name or owner and is a small inconsistency that the badges carry around.

The primary language is Kotlin, the licence is GNU General Public License v3.0, and the project is not archived.

There is a CODE_OF_CONDUCT.md at the root, which is the governance document the project publishes, and the repository has an .editorconfig and a .gitignore, and the top-level structure is otherwise the standard Android set of configuration files, the settings and the wrapper.

Maintenance, and what the release history shows

The release history is dense and recent. Version v1.17.1 was tagged on 2026-06-06, v1.17.2 on 2026-07-15 and v1.17.3 on 2026-07-18, and the last push to the repository was on 2026-09-02.

The cadence is worth reading carefully, because it is not the cadence of a hobby project that touches something once a year. Two patch versions nine days apart in July, and a month of further work on the branch after the last tag, is the rhythm of a utility that is maintained for the current Android releases rather than for one device.

The numbers also say something. The project is on a 1.x line, which for an Android utility of this kind means the API surface has been stable for a long time, and the recent work is compatibility and packaging rather than redesign. The version numbering does not encode any major rewrite.

For anyone installing it, the practical consequence of that cadence is that there is a recent build to use, and that a build from the Play Store or from F-Droid is likely to behave differently on a recent Android release than the version you had last year. The tutorial the README points at is the thing to re-check after a major Android update, because the permission grant procedure is the part most likely to change.

Editorial conclusion

Adopt Geto if you need to change a secure setting on an Android device without digging through the Settings app, and you are comfortable granting an app a privileged permission and reading its documentation rather than trusting a store listing. Do not adopt it expecting it to manage a whole device, because the project describes a narrow utility with one origin story, and expect the real friction to be the permission grant rather than the app. Before you start, read the tutorial the README points at, and check the version you install against your Android release, because the recent releases are frequent and the permission behaviour is what determines whether the thing works on your device.

Frequently asked questions

Official sources

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