mirror of
https://github.com/binwiederhier/ntfy.git
synced 2026-05-09 08:26:00 +02:00
[GH-ISSUE #580] Update the Android GUI to Google's Material 3 / You style. #440
Labels
No labels
ai-generated
android-app
android-app
android-app
🪲 bug
build
build
dependencies
docs
enhancement
enhancement
🔥 HOT
in-progress 🏃
ios
prio:low
prio:low
pull-request
question
🔒 security
server
server
unified-push
web-app
website
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ntfy#440
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @RokeJulianLockhart on GitHub (Jan 12, 2023).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/580
For AOSP. My rationale is available at
RokeJulianLockhart/RokeJulianLockhart/issues/4.@binwiederhier commented on GitHub (Mar 31, 2023):
Reference - @Bnyro implemented this here: https://github.com/binwiederhier/ntfy-android/pull/56
@mpeter50 commented on GitHub (Apr 28, 2024):
I don't know about the possibilities, but if not too much of a burden I (and probably others too) would prefer to keep the original Material design.
Material design 3 does not only introduce customizable colors, but also many other changes that are not customizable however quite ugly: these include unnecessary larger whitespaces, and largely rounded corners.
Contrary to the above rationale, from my side at least sticking with Material (1) does not mean that the software is unmaintained, and I don't think many are thinking that way. In my opinion, the appearance of the software is consistent with the latest tasteful version of the Material Design Guidelines.
The app's current version may not be fashionable, but usability is unaffected.
@RokeJulianLockhart commented on GitHub (Apr 28, 2024):
@mpeter50, I'd say that it's more akin to what
m2.material.io/design/introduction#baseline-griddescribes than whatm1.material.io/material-design/introduction.htmldoes.@TecdataOfficial commented on GitHub (May 8, 2025):
Apps can absolutely utilize the guidelines within a reasonable and customizable scope that fits their a usable design for them. Ie. Developers don't have to use the large margins and can use the guidelines to fit the characteristics of their app. By characteristics, one example could be Material 3 style presentable and friendly information cards for each notification / message without unnecessarily using up screen space real-estate. Designs and controls can use elements that make information flow easier and brings new options for easily showing the user additional screens or slide out views. On larger screen sizes, these views can dynamically show together, on small screen sizes the elements scale appropriately.
Better more usable and accessible UI elements: It's also important to understand why Material 3 exists the way it does. I'm not advocating for large white spaces and margins which can certainly waste screen space of certain apps and how they present their information. However, I'm certainly an advocate of accessibility and UI scalability. You need to keep in mind, Android is used on a variety of screen sizes, device types, PCs, Dex UI containerization, split screens, foldable phones. Google engineers worked very hard on exceeding accessibility requirements, and their reasoning is quite sound for many of the design choices they made.
However, if you look at many Google apps, they don't use every single Material 3 element outlined, many exclude tinted backgrounds and large tinted elements, etc; they may use 60% of the elements. It's all about pleasing aesthetics in an accessible fashion. Accessibility and Material 3 needs to fit to the app's characteristics and information flow, giant margins are not for everyone.
Let's discuss rounded corners for a second: This isn't just a new hip fashion. There is a sound design decision around this. Rounded corners with color offsets for inner elements, as opposed to Material 2 which has a corner rounded px of around 4 and shows inner elements without inner color offsets, doesn't make things as easy to understand or find.
Eg: A dialog with a question in M. 2 is a white rectangle with capital blue letters for each button. There's no distinction between which option is the best choice for the user. M. 3 suggests that the tap targets should be rounded corner buttons with slight background color variations to distinguish them; the best option for the user or the option the user has selected in the past, should be a darker tone to direct their attention to that button. If the user knows what the dialog says, tapping the appropriate button is quick. Material 2 makes no such usability. Essentially, rounded corner elements with color offsets subtly direct attention inward, helping users focus on the content inside a button or container, and tap the best choice action.
Material 3 does not subtract from usability. If it does, then it's implemented wrong. It should add additional usability, it should make things more friendlier, especially from a design and aesthetic point. Material 3 is designed to be more usable and accessible
@mpeter50 commented on GitHub (May 8, 2025):
Accessibility certainly does not need 10px and more rounded corners. There is a tasteful amount. In my opinion, that is way, way below that (and not 0, mind you).
Margin sizes should be based on settings, possibly system settings, instead of making smaller screens unusable, and thus also forcing people to not even consider phones with smaller screens. We already have this for 3 different parameters about animations, but this one should be more accessible.
That way users with bigger thumbs can use UIs conveniently.
Well I agree its not new, this madness has been going for years now. Under the flag of customizability, where the only possibility for me to customize is by writing an Xposed module that makes the changes.
I'll be honest here and tell you that I dont know what kind of color offsets on inner elements are you referring to, especially the inner element part. Colored text with color based on accent color? But I dont see how rounding the corners are helping here, so probably not that.
The distinction was always being made with colors, wasn't it? Also, rounded corners for the button does not seem to be a meaningful thing here. Sure, do not keep the buttons with sharp pointy colors but why apply 15px radius? 2-3 px is totally fine.
Then that means it has no single correct implementation, and something somewhere is entirely broken.
Achieving that goal does not need any amount of forced rounded corners and forced large margins.
The only thing I can understand about these two is large margins, as I said, for people with big thumbs. Let it be configurable for them, preferably systemwide. But do not force it.
@RokeJulianLockhart commented on GitHub (May 8, 2025):
@mpeter50, I'd be amazed if anyone disagreed with you on this, but it's nigh infeasible without a very homogenous GUI toolkit landscape. Irrespective, it's out-of-scope for this issue, but if you bring it to
issuetracker.google.com, although futile, I'll support you.@binwiederhier commented on GitHub (Dec 11, 2025):
This is now merged and will go out with ntfy Androud 1.19.x
@binwiederhier commented on GitHub (Dec 11, 2025):
@cyb3rko and @RokeJulianLockhart and everyone else who'd like to test:
Untested:
Known bugs:
@RokeJulianLockhart commented on GitHub (Dec 11, 2025):
@binwiederhier, the window decorations / title bar of
1.19.0-debug, invoked asam start --windowingMode 5 io.heckel.ntfy.debug/io.heckel.ntfy.ui.MainActivity, 1 shouldn't be colourised, nor should elements render outside the window border, and atop one-another, rather than moving into the overflow context menu:...and its banner shouldn't be rounded at the top (due to the toolbar), unless it gains a margin around its border. However, that'd be a waste of space. It's slightly better with monochromatic dynamic colouration, 3 however, but that's niche:
android.stackexchange.com/revisions/263426/2↩︎chatgpt.com/c/693b0545-0748-8332-97f5-b6072087367e↩︎chatgpt.com/s/t_693b065808a08191826688df8d4701cb2 ↩︎@binwiederhier commented on GitHub (Dec 20, 2025):
github.com/binwiederhier/ntfy-android@74968ac2e2github.com/binwiederhier/ntfy-android@62fac9ce68I'll release a new 1.19.1-rc1 to Google Play and publish in https://github.com/binwiederhier/ntfy-android/releases
@RokeJulianLockhart I honestly don't know what you're trying to tell me with the window decorations and title bars. How does that manifest when started normally on the phone?
@binwiederhier commented on GitHub (Dec 20, 2025):
Another tiny fix:
github.com/binwiederhier/ntfy-android@99086f98aeI'll release a new 1.19.2-rc1 to Google Play and publish in https://github.com/binwiederhier/ntfy-android/releases
@RokeJulianLockhart commented on GitHub (Dec 21, 2025):
@binwiederhier, apologies for the wait. Been quite unwell. I merely mean that:
when in, what Quickstep refers to as, “Freeform” mode, the colour of the window's title bar should match the background
the battery notification's buttons should either become a context menu, or a minimum window size should be applied. The former is, likely, easier than the latter (and more adaptive; useful for something like a smart-watch)
the battery notification should be padded around its sides, or unrounded where it meets the header
@binwiederhier commented on GitHub (Dec 23, 2025):
This is being released now.
@RokeJulianLockhart Lots of folks have tested it and it seems fine for them. How can I test/reproduce what you are doing? Do you have a different kind of device? I am closing this ticket, but we can have follow up pull requests and tickets any time!
@RokeJulianLockhart commented on GitHub (Dec 23, 2025):
@binwiederhier, you should be able to confirm any of that on
waydroid-1.6.0-3.fc43.noarch, with:…except the colouration, which must be modified at:
I'm uncertain of what this means, but my environment is:
@cyb3rko commented on GitHub (Dec 24, 2025):
@binwiederhier To answer the question:
He seems to use some kind of desktop connection to his phone. But which one, I don't understand.
@RokeJulianLockhart Maybe give us some more details on which software you use?
@mpeter50 commented on GitHub (Dec 24, 2025):
I suspect he first experienced the issue on his Fairphone 5, then he was able to reproduce it with waydroid (an android "emulator" for linux), and shared the details on how to reproduce it with waydroid, believing that its easier to reproduce the issue that way.
@RokeJulianLockhart commented on GitHub (Dec 24, 2025):
@mpeter50, exactly. All of that was conducted on a real OEM AOSP installation. @cyb3rko, I've already provided what you ask for, in the
getpropoutput (thero.*keys). However, this might be reproducible inandroid-studio-2025.2.2.8-1.fc43's1 /sdkmanager, too:avdmanagerbugzilla.redhat.com/show_bug.cgi?id=2422333↩︎@cyb3rko commented on GitHub (Dec 24, 2025):
@mpeter50 provided what I was looking for.
The usage of Waydroid is the most important information in this thread, because on all physical phones it seems to work fine.
@mpeter50 commented on GitHub (Dec 24, 2025):
The way he phrased it makes me think he also has this problem on a Fairphone 5.
@RokeJulianLockhart commented on GitHub (Dec 24, 2025):
@mpeter50, thanks again. Indeed, I do.
@cyb3rko commented on GitHub (Dec 25, 2025):
So you are referring to those two screenshots, which seem to belong to a physical phone, right?
Because they show a titlebar as expected, I would say.
Or what else is wrong here? Unfortunately I still don't quite understand
@RokeJulianLockhart commented on GitHub (Dec 25, 2025):
@cyb3rko, I was referring to all of the screenshots.
Those screenshots don't show a title bar, at all.
isInMultiWindowModewould returnfalse.I have even explained what the exact problem is, and provided the
exec-out uiautomator dump /dev/ttyoutput to empirically demonstrate which elements I'm referring to, in the cited activity. Instead of asking me to essentially prove a negative, please elaborate on what you don't understand, so that I can rephrase.@cyb3rko commented on GitHub (Dec 25, 2025):
Then we are talking about different things here, because officially there is not title bar.
To speak in Android lingo, I mean the "Top abb bar" (https://m3.material.io/components/app-bars/overview), which is clearly there in your screenshots.
Do you mean the "Status bar" (https://developer.android.com/design/ui/mobile/guides/foundations/system-bars#status-bar)?
Maybe I'm just stupid. Please give me the steps how I can replicate your issue on my physical phone, without any CLI commands or emulator tools from inside the app itself.
If the scope is not the ntfy app but some emulation tool, I'm gonna leave that to other contributors.
@binwiederhier commented on GitHub (Dec 25, 2025):
I am feeling equally lost. We want to help but I think we legitimately do not know what you're talking about. You speak about stuff that I've never heard before, like you're talking about the engine of something, but I don't know if you're talking about a car or a plane or an electric toothbrush. Please ELI5 it for us. What are you talking about? ;-)
@mpeter50 commented on GitHub (Dec 25, 2025):
I think the bugs he found are those that can be seen on the screenshots here: https://github.com/binwiederhier/ntfy/issues/580#issuecomment-3643155223
On the first 3 screenshots, the app is opened in Freeform/"windowed" mode. This was partly added to android for desktop usage with an external screen, but it can be useful on the phone screen too.
How to test windowed mode: some launchers allow you opening apps in windowed mode, including the Quickstep launcher, which is the base of the google pixel phones' launcher.
Other than that, you can also move already open apps into windowed mode: open the task manager on the navigation bar, and depending on your android flavor tap a recent app's icon and select "freeform" from the menu that just opened, or like on xiaomi phones long tap a recent app's screenshot in this same menu and one of the buttons that appear should move the app into freeform windowed mode.
An app can also be started in freeform windowed mode with
am start --windowingMode 5 <package name>/<activity name>(didnt check the command but looks fine).You can use these ways for testing on your phones.
As I see, the problem in this mode is that the window frame (that has back, minimize, maximize, close buttons) is colored with the app's accent color, instead of the status bar color, and this is probably distracting.
Another complaint that windowed mode highlights is that on small screens, in small windows, and when a vision impared user has set their screen content magnification to very large, there are some issues.
For one, on the title bar of the "subscribed topics" activity the bell icon is forced to be shown. It may be better if even that icon could be collapsed into the 3 dots menu.
But also, the buttons in the battery optimization warning box are hardly clickable because they dont fit in the window, and the "plus" floating action button overlaps this warning box further making it harder to be used.
Yet another complaint is that on the "subscribed topics" activity, the battery optimization warning box has the top corners rounded, which looks a bit weird when this warning box touches the toolbar.
He has written some suggestions here on how it could work insetead.
The XML output in this comment is made by an android developer tool, I guess he pasted it in to help debugging as it shows the structure of the views in the app.
@RokeJulianLockhart commented on GitHub (Dec 25, 2025):
@cyb3rko, I referred to two distinct attributes (not problems, per se, but opportunities for improvement), so I need to know which you're referring to. Specifically, when you state that “there is not title bar”, I presume that you're referring to your cited “top app bar”, visible even with
<meta-data android:name="com.sec.android.support.multiwindow" android:value="false"\>, rather thanWindowManager's title bar, which does exist, per the aforecited:am start --windowingMode 5 io.heckel.ntfy.debug/io.heckel.ntfy.ui.MainActivity; I've even screenshotted it.If so, I'm not. I'm referring to
WindowManager's, accessible via whatandroid.stackexchange.com/revisions/263426/2explains, and what I've aforestated.No. That's
com.android.systemui's purview.I doubt that you're stupid. 😊 However, I find you asking me to provide replication steps without using the CLI a little lazy; CLI steps are easy to test, empirical, and significantly more reproducible. (What happens if you're on AOSP 12 or 16, and I'm on 15? The GUI shall differ.)
Regardless, I'll try. However, the sole thing that I imagine that you might require documentation for, might be invoking the application in freeform mode, because the rest is very basic. If so, see the screenshot that I've uploaded to
android.stackexchange.com/revisions/261679/1. If not, as aforestated, please elaborate on specifics.I've already informed you that I reproduced everything I've stated on a bare-metal AOSP installation on real, consumer hardware. I wouldn't even recommend an emulator for this, due to
farmerbb/Taskbar/issues/3521 making this difficult to confirm outside of real OS installations.@mpeter50, after writing all that I just did, I've realised that you've more courteously and helpfully explained all that I have, so consider this to be a corroboration; my sincere thanks for all of your assistance thus far. @binwiederhier, I hope that these, combined, explain.
reddit.com/r/GooglePixel/comments/1nvn3qm/comment/nvy18j1↩︎