ShaderEditor: writing GLSL on an Android phone and running it as live wallpaper

A shader editor that lives on the phone

ShaderEditor creates and edits GLSL shaders on your Android phone or tablet and uses them as live wallpaper. That is the whole product, and the constraint of running on a phone shapes every part of it.

The app is published under the package name de.markusfisch.android.shadereditor and is available on F-Droid as well as on Google Play, with the Play Store listing as the homepage in the repository metadata. The licence is MIT.

The primary language is Java, though the build is Gradle with Kotlin build scripts, `build.gradle.kts` at the root and a `settings.gradle`. The repository is a normal Android project layout with an `app/` module, a `gradle/` wrapper directory, a `gradlew` script, and `fastlane/` holding the store metadata and the screenshots the README embeds.

Two directories in the tree suggest where the project is going. `docs-site/` is a documentation site that is not part of the app, and `svg/` with an `update.sh` script is for regenerating the vector artwork, which the Makefile exposes as the `images` target. There is also an `AGENTS.md` at the root, which in this repository is a sign that the project is set up for automated contribution tooling.

The project is actively maintained, with version 2.36.3 tagged on 2026-10-09 and the last push the same day.

The feature list, and what a phone can actually feed a shader

The features list is short and tells you what the runtime exposes to your shader.

Use any shader as live wallpaper is the reason the app exists. Alongside that, live preview in the background or on an extra screen, syntax highlighting and error highlighting in the editor.

The rest is the interesting part, because it is a list of what an Android device can hand to a fragment shader. Sensors are exposed: camera, accelerometer, gyroscope, magnetic field, light, pressure and proximity. Battery level is exposed. The wallpaper offset is supported, which lets a shader react to where the user has dragged the wallpaper image. Multiple touches are supported, so a shader can respond to more than one finger. Multiple render resolutions are supported, and the previously rendered frame is available in a backbuffer texture, which is the trick that lets a shader build trails and feedback effects by sampling what it drew a moment ago.

Textures can be imported and used, and cube maps can be created and used, so reflections and environment mapping are within reach.

The last feature is a power decision rather than a graphics one: rendering is disabled when the battery is low. A live wallpaper that runs a fragment shader every frame is one of the more expensive things a phone can do, and a live wallpaper that keeps the device awake in a pocket is worse. The feature list shows the author thought about the cost of running it continuously.

Building and installing it from the Makefile

The Makefile is a convenience wrapper over Gradle and adb, and it is the only build documentation in the repository.

The default target chains everything:

all: debug install start

which builds a debug APK, installs it on a connected device and launches it. The individual pieces are straightforward. `make debug` runs `./gradlew assembleDebug`, `make release` runs lint first and then `./gradlew assembleRelease`, and `make bundle` produces a release bundle with `./gradlew bundleRelease` after linting.

Installation and launch use adb, with the package name from the Makefile:

adb $(TARGET) install -r app/build/outputs/apk/debug/app-debug.apk
adb $(TARGET) shell 'am start -n \
	$(PACKAGE).debug/$(PACKAGE).activity.SplashActivity'

The `$(TARGET)` variable is left undefined in the Makefile, so it is meant to be set on the command line for a specific device, and the `-r` flag on install means the existing app is replaced rather than removed first.

The remaining targets are diagnostic and maintenance. `make meminfo` dumps the package's memory information through `adb shell dumpsys meminfo`, and `make glxinfo` does the same for graphics info with `dumpsys gfxinfo`. Both are aimed at a developer checking what the app is doing on a device, and they are the kind of tooling that tells you the project is meant to be worked on rather than only used.

`make clean` runs `./gradlew clean`, `make lint` runs `./gradlew lintDebug`, and `make infer` runs the Infer static analyser over a clean debug build.

Where the project's own material lives

The repository tree contains the things a small but well-run project tends to accumulate.

There is a CHANGELOG.md, a CONTRIBUTING.md, a CONTRIBUTORS.md, a PRIVACY.md and a LICENSE file, plus a FAQ.md that the README points to for frequently asked questions. An .editorconfig at the root, and a .github/ directory for the workflow configuration.

The FAQ.md file is worth singling out, because the README defers all questions to it rather than answering them inline. That is a reasonable choice for a project with a narrow but detailed feature set, since the interesting questions are all about specific shader capabilities rather than about installing the app, and it keeps the README short. It also means the README alone is not a complete picture of what the app can do, and a reader who wants the fine print has to open a second file.

The PRIVACY.md file is the other one to notice. An app with camera access, sensor access, battery level reading and a live wallpaper running in the background is an app that could in principle be reporting what it sees, and having a privacy document is the minimum answer to that. The topics on the repository are android, glsl, shader-editor and shaders, which is a deliberately technical list with no monetisation or analytics topic attached, and the app is on F-Droid as well as Google Play.

The homepage of the repository is the Play Store listing rather than a separate website, which again points to a project that is a working application first and a community hub second.

What a phone shader environment cannot do

The boundaries of the platform are worth stating plainly, because the feature list can read as more capable than it is.

The shader language is GLSL, and the runtime is an Android device GPU, so this is OpenGL ES shading rather than desktop GL. The uniforms available are the ones the app exposes: sensor values, battery level, wallpaper offset, touches, render resolution, the backbuffer texture, imported textures and cube maps. There is no filesystem access, no network fetch, no arbitrary texture generation, and no way to bring in a geometry or compute shader pipeline, because a live wallpaper is a fragment shader running over the screen.

That is a real limitation for anyone expecting to develop a production shader, and it is also what makes the app pleasant. The whole loop, edit, compile, see it running, set it as the wallpaper, takes seconds on a device that is already in your hand, which is a much faster loop than a desktop setup for a simple fragment effect.

The second limitation is the editing environment. Syntax highlighting and error highlighting are the extent of the editor's support. There is no project system, no asset pipeline beyond importing a texture, and no version control, because the shaders live on the device rather than in a repository. A shader you write here is a shader you have copied out of the app to keep.

The third is the same one every wallpaper app has: it runs when the screen is on and the wallpaper is visible, and the app's own battery safeguard means the experience changes when the battery is low. For a decorative effect that is the right trade, and for anything you want to run all day it is not.

Editorial conclusion

ShaderEditor fits an Android user who wants to sketch a GLSL shader on a phone, see it running immediately, and keep it as a live wallpaper, and a developer who wants a small readable reference for how OpenGL ES rendering is wired into an Android app. It does not fit someone who needs a full shader development environment with version control, and the shader is written in GLSL with a limited set of uniform inputs, so it is not a path to complex production shaders. Before you start, read FAQ.md in the repository, and if you build it yourself, run `make debug` followed by `make install` and `make start` with a device attached over adb.

Frequently asked questions

Official sources

1. License: MIT
2. markusfisch/ShaderEditor on GitHub
3. Project website
4. README
5. Releases