What 'always on' really costs
Keeping an app visible on screen indefinitely sounds simple. On modern Android it involves foreground services, battery behaviour, burn-in and a permission you have to justify.
"The clock should just stay on the screen" is the kind of requirement that sounds like it takes an afternoon. On modern Android it is one of the more constrained things you can ask for, and the constraints are all reasonable ones.
Android does not want your app to stay running
The platform has spent a decade getting better at stopping apps that are not in the foreground, and it is right to. Background work is the main way a badly-behaved app destroys battery life, and users overwhelmingly benefit from an operating system that is aggressive about it.
The legitimate exception is a foreground service: a declared, user-visible, ongoing task. Music playback is the canonical example. An always-on clock display is another — the entire value of the product is that it does not stop.
Using that permission means justifying it, both to the platform and in the store listing. It is not a loophole to keep an app alive; it is a declaration that the app is doing something the user has explicitly asked to keep happening. If your app cannot make that case honestly, it should not use it.
Battery is a design constraint, not a bug report
An app that holds the screen on is spending the most expensive resource on the device. There is no clever engineering that makes that free, because the display is the cost.
What you can do is give the user real control over how much they spend. Dimmable brightness is not only a comfort feature — at low brightness an OLED panel genuinely draws less power, and a mostly-black clock face with a few bright digits is close to the best case for that. Auto-close options let someone cap the spend without having to remember to close the app.
The principle we settled on: never make the battery decision on the user's behalf, and never hide what the decision costs.
Burn-in is the one you cannot patch later
Static, bright, high-contrast, unchanging, for hours at a time. If you set out to design content that causes OLED burn-in, you would arrive at a large digital clock.
The mitigation is not complicated — shift the rendered image slightly over time so no pixel is permanently responsible for the same bright element — but it has to be designed in from the beginning, because it changes how you lay the screen out. You cannot have elements pinned hard to the edges if the whole composition needs room to drift.
It is also the least visible work in the product. Done properly, nobody ever notices it. The only way a user finds out whether you did it is months later, and by then it is too late to fix.
The pattern
Each of these is the same shape: the feature the user wants is simple, and the platform constraint behind it is not. The temptation is to route around the constraint. The constraints here exist because of real damage — flattened batteries, ruined screens, apps that quietly run forever — and the better move is to design a product that works within them and is honest about the trade-offs it is making.