Red Moon: an Android screen filter that dims and reddens the display at night

A filter that dims below the normal minimum, not just a colour shift

The premise is medical and simple. Blue light may suppress the production of melatonin, the sleep hormone. Red Moon filters out blue light and dims your screen below the normal minimum, so you can use your phone comfortably at night.

The two mechanisms are separate and both matter. A blue light filter that only shifts colour still leaves a screen bright enough to be harsh in a dark room, and a dimmer that only reduces brightness does not remove the blue component that is associated with the melatonin effect. Doing both is why the app is not simply a colour temperature slider.

The feature set in the readme is short and specific. You can schedule Red Moon to run from sunset to sunrise, or at custom times. You can use the default color profiles, or set custom color, intensity, and dim levels. It can automatically pause in apps secured against overlays, or those you choose. And you can quickly start, stop, and switch profiles via notification, tile (Android 7.0+), or widget.

The overlay point is the one that shows the author has thought about Android properly. Many apps draw a secure window, such as a banking app or a video player with DRM, and a screen filter implemented as an overlay cannot be shown on top of it. A filter that paused itself in those cases rather than flickering or showing an error is a small design decision that avoids an entire class of complaint.

The project is written in Kotlin, distributed under GPL-3.0-or-later, and published on F-Droid with a direct APK download as well.

The readme opens by saying the project is not maintained

The first line of the readme is a heading reading Not Actively Maintained.

The sentence that follows is unusually well judged for a project in this state. Red Moon is no longer maintained, but Pull Requests are still accepted. The author adds that he is also willing to deputize PR authors as co-maintainers, and points to a specific issue, 281, for the detail.

That is a different posture from an abandoned repository, and it is worth separating from the other kind of unmaintained project, the one that is merely quiet. A quiet repository gives you no signal at all. This one tells you the state of things in the first sentence, tells you what it will still accept, and tells you how someone can take over.

The dates support the claim. The most recent tagged release is v4.0.0 from 2022-08-14, before that v3.5.0 from 2020-03-03 and v3.4.0 from 2019-02-03, whose release title is Support newer and older devices. The repository is not archived and the last push was on 2026-05-18, so commits still land, but they are not accompanied by releases.

For an adopter, the practical reading is that the application is a finished artefact that may or may not work on a current Android device, and the maintenance path runs through outside contributors rather than the original author. The readme also states the screenshots are slightly out of date, which is a small but telling detail about how much the presentation has moved with the code.

The privacy policy is specific about what is stored and what is discarded

Red Moon collects data only when it is necessary for functionality. These features are all disabled by default. If you enable them, the data never leaves your device.

The policy then names the two features that touch data at all.

If you use the Sunrise to Sunset feature, Red Moon will store your location, latitude and longitude, and you can see them in the preference. It is used in order to calculate sunrise and sunset times. So the location is stored locally, shown to you, and used for one calculation.

If you use the excluded apps feature, then while Red Moon is running, it will monitor what app is in the foreground and which screen of that app is open, currently it polls once per second. This is checked against the list of excluded apps to determine whether Red Moon should pause, and then is immediately discarded. If you choose to exclude an app, then it's stored to the list of excluded apps, until you remove it.

The debug build adds one detail. In the debug version of the app, these are logged to the Android system log, logcat. These logs are not accessible to other apps on the device, and on most versions of Android they are cleared after 1 to 7 days.

This is the section that sets Red Moon apart from the genre. A screen filter that runs all day in the background and watches which app is in the foreground is exactly the kind of app that deserves scepticism, and the answer here is written down, bounded, and off by default. The polling rate is disclosed, the retention of the foreground data is described as immediate discard, and the location stays on the device.

Building from source, and the licensing of the pieces inside it

The build is documented for GNU+Linux, and it is a standard Gradle project. Clone the repository, then from the root directory run:

./gradlew build

To install the app on a connected device or running emulator:

./gradlew installDebug

The tree matches a normal Android app project. There is an app directory, a build.gradle, settings.gradle, gradle.properties, the gradle wrapper with gradlew and gradlew.bat, and a separate timepickerpreference directory, which is the custom time picker preference that the schedule feature needs. There is also a LICENSE.md, a LICENSE.spdx file, art for the icon assets, and the usual .github and .gitignore.

The licensing is more interesting than the usual single file, and the readme is explicit about it. Red Moon is licensed under the GNU General Public License version 3 or, at your option, any later version, by the contributors. It is a derivative of Shades by Chris Nguyen, used under the MIT License. All used artwork is released into the public domain, and some of the icons use clip art from openclipart.org, which are also in the public domain, with five specific entries listed by URL.

So the project is a GPL-3.0-or-later work built on an MIT licensed original, with the artwork in the public domain. That combination is what allows the F-Droid listing, which typically requires a clear licence and a build that can be reproduced from source, and the presence of both a LICENSE.md and a LICENSE.spdx file is consistent with a project that cares about licence clarity.

A translation project as much as a code project

The readme spends a surprising amount of its space on community participation, and a good part of that is translation rather than code.

The headline is a section called Do your part, participate in the community, with the argument stated plainly: communities keep software projects alive, and without them, projects usually fade into obscurity when the primary developer loses interest or becomes busy in other parts of their life. The listed ways to help are to read through the issues, open new issues with feedback or feature requests or bug reports, help translate using Weblate, and come chat on Matrix, IRC or Gitter.

The translation infrastructure is real rather than aspirational. There is a Weblate widget and an engage badge, the project has a translation status badge, and the readme notes that contributors should keep code and translations in separate pull requests. The pull request guidance also says the maintainers are happy to answer questions through an issue, a chat room or email, and that if a change makes the UI more complicated, it is worth checking whether they are interested before implementing it.

There is a style guide too, and it is short enough to quote. Prioritize legibility over dogmatism, though consistency is nice. 100 characters per line, 80 if you can. Indent 4 spaces, or 8 if the previous line ends with =. CONSTANTS and ENUMS use all caps, variableNames use camelCase. Form suggests function, so group and align similar actions and do not align dissimilar ones. Good comments explain why something is done, and if a comment describes what the code does, the suggestion is to refactor into smaller functions with descriptive names or convert the comments to logs, on the reasoning that code requiring comments also requires good logs to debug. Always use curly braces with if, except short val or var one-liners.

For an unmaintained project, a written style guide is what stops the remaining contributors from drifting apart.

What you get by installing it, and what you do not

It helps to be clear about the category. Red Moon is a filter, not a system-wide dark mode, not a screen-time tool and not a blue light blocking app that also blocks notifications.

What it does is take the display and reduce the blue component while lowering brightness, on a schedule you control, and step out of the way when an app needs a secure window. The controls for that are a colour profile choice plus intensity and dim levels, and the trigger is a schedule from sunset to sunrise or custom times. The tile and widget and notification controls exist so that you can override the schedule in the moment, which is the behaviour people want when they are still using the phone and do not want the filter yet, or want it back on.

What it does not do, according to the readme, is anything about the time of day other than the schedule, it does not adjust the display automatically based on ambient light as far as the documentation states, and it does not offer per-app dimming outside the pause list, where the excluded apps feature is a pause mechanism rather than a separate profile per app.

The most significant limitation for a current user is probably the plainest one. The newest release is v4.0.0 from 2022, and Android has moved on considerably since then in ways that affect overlay based apps, in particular the tighter background restrictions and the changes around overlay permissions. The project was written when those constraints were different, and the readme's own admission that the screenshots are slightly out of date is a smaller version of the same point.

Because the code is on GitHub and the build is a standard Gradle invocation, the community path is available: fork it, build it, and run it. That is the reason the author is willing to deputize co-maintainers. The F-Droid build and the direct APK download are the fast routes for a user who just wants the app.

Where Red Moon is the wrong choice

There are several cases where this is not the tool, and they are worth naming.

The first is if you need an actively maintained filter. The project says in its first line that it is no longer maintained, the newest tag is from 2022, and the offer is to accept pull requests. If you are putting a screen filter on a phone that your family or your company depends on, an unmaintained app is a poor foundation, because there is nobody whose job it is to answer an issue when a new Android release changes overlay behaviour.

The second is if you want a feature set beyond the filter. This is a night filter with a schedule. If your actual need is automatic dark mode tied to the system setting, or a per-app dimming profile with separate settings for each app, or blocking of specific content, you are looking for a different application, and the excluded apps feature here is a pause list rather than a per-app configuration.

The third is if the foreground monitoring makes you uncomfortable even with the policy. The excluded apps feature requires the app to poll once per second to see what is in the foreground and which screen of it is open, and that only works while Red Moon is running. The policy says the data is discarded immediately and stays on the device, and the debug build additionally writes to logcat. If you would rather the app never looked at your foreground app at all, that feature should stay off, and the price is that the automatic pause will not happen.

The fourth is if you are on a platform where the overlay technique is blocked. The feature list promises automatic pausing in apps secured against overlays, which shows the author knew about that case, but the base filter still has to draw an overlay, and a heavily locked down or work managed device can refuse that. Nothing in the readme covers what happens then.

And the fifth is simpler. If you want a system that also handles schedule, brightness, focus and notifications together, then a screen filter is the wrong size of tool, and the gap between the two categories of app is wide enough that substituting one for the other does not work.

Editorial conclusion

Adopt Red Moon if you want a single-purpose night filter on Android and are comfortable with an app its own maintainer has marked as unmaintained, since the feature set is exactly what the readme promises and the privacy stance is unusually clear. Skip it if you need an actively developed filter with a current Android release, because the newest tagged version is v4.0.0 from 2022-08-14 and the last push was on 2026-05-18. Verify first that it still installs and runs on your Android version, that the sunrise to sunset feature gives you a usable schedule at your location, and that the excluded apps list pauses it in the apps that block overlays.

Frequently asked questions

Official sources

1. Issues
2. LibreShift/red-moon on GitHub
3. License: GPL-3.0
4. README
5. Releases