"First we write the bad code, then we write the good code."

Your concerns are valid but not unique to AI generated code, the same feeling has existed for as long as open source software has existed: is my code good enough, will I just look stupid when people suggest oversights and mistakes?

The fact of the matter is that if you have created software that solves an actual issue, especially if that issue was previously unsolved, you have created something valuable. Making it open source only means that the code is now open to contribution, forks, or other modifications by anyone using it.

The performative idea of open source software being a part of your resume and written only to increase your personal brand is a perversion of what the open source movement originally was about. It's about learning, and you learn by making mistakes, regardless of whether your bad code was written completely from your own brain or from the suggestion of an LLM.

Don't ever be afraid to open source your code, nobody has any right to expect anything from you, and if they do they are just too stupid to understand that free and open code is always a gift, regardless of how bad it is, if it solves a problem for real people.

Appreciate the transparency about the AI-assisted development. Your concerns about code quality are valid, but you're overthinking it. We've all shipped worse code that we wrote ourselves.The real win here is that you listened to feedback and made it verifiable. That's what the privacy-conscious Android community needed. The fact that it already works well in production is a bonus.

the shame around vibe-coded stuff is real but honestly - most of the code out there wouldn't survive scrutiny either, AI-generated or not. the difference is that vibe coding fails in predictable patterns. weirdly verbose error handling that doesn't actually handle the error, auth flows that work great until you send a malformed header, things like that.

for notifications specifically, the risky bits would be: what happens if an app sends a notification payload that's malformed or huge, how do you handle permission checks if the notification system process restarts mid-filtering, and whether the filtering rules can be bypassed by crafting notifications with weird mime types or encoded text.

if you wrote tests for those edge cases (or even just thought through them), you're already ahead of 90% of shipped code, vibe-coded or not. the scrutiny you're worried about is actually healthy - peer review catches stuff automated tools miss.

Good for you.

FWIW, I suspect there isn't a single programmer you admire that hasn't looked back on moments in their career and cringed at some of their own code.

In some ways, I think it is the hurdle that Linus overcame as an undergraduate that I admire the most. Just putting it out there. This is code. Look at it. It might not amount to anything, but who dares wins.

Very proud of you for doing this! I think attitudes around vibe-coded software have been changing a lot over those past two months. Not just on a single axis of "accepted" vs. "rejected" but evolving along many axes. Thank you for helping Android users customize their digital environment.

Ever since iOS introduced "reduce interruptions" mode I've been using it ever since and it's really great. It's not as customisable as this app, but I still highly recommend anything like this for those who're tired of notifications spam

Why does Android need this? Does the OS not let you control notifications?

Android does, at the level of "Allow notifications from app X" and "Block notifications from app X".

DoNotNotify gives granularity and rules (which a specific app may have chosen not to implement).

For example:

    "Allow <budget airline app X> to display notifications of gate changes"
    "Block <budget airline app X> from displaying advertising notifications"

Android 15/16 does allow you to control notifications even lower, at the level of notification category, but indeed the app must have chosen to use them.

Most apps that are in need of notification control either:

a) bundle everything in one category, from critical notifications without which the app can't fulfill its purpose to "HEY YOU HAVEN'T USED ME IN A DAY, USE ME NOW" spam

b) create a new category for spam every time they feel enough users have turned off the previous one, which is often

Companies do it with email unsubscribe categories to, which is skirting laws for sure.

I wish app review checked for this. It's hostile anti user behavior.

Yeah the problem is a lot of apps dump their ads in the wrong category if they even use categories :(

OEMs like Samsung turn off that ability by default unless you toggle it in "advanced settings". Thank you Samsung!

To give you an example of what this is form, some apps like to bundle notification categories in such a way that the Tracking notification is the same as the "Buy this item on sale" notification and you can't granularly turn it off. It's 100% intentional.

I assume this allows more granularity. Many apps avoid you blocking their marketing by not using the notification categories system. It's all or nothing. This app would presumably allow me to differentiate between the two if it can't be done with notification categories.

It does, but this appears to have a lot more granularity. You don't always want to block an entire app, sometimes you just want to block some of the notifications from a specific app.

I use FilterBox and Buzzkill.

FilterBox does seem to be superior with an inbuilt offline ML model to filter spam notifications, whilst also having a robust set of heuristic filtering options.

It's also amongst the snazziest apps to use with a design that delights. Best lifetime IAP I made 7+years ago.

FilterBox: https://filterbox.catchingnow.com/ Comparison post: https://www.reddit.com/r/androidapps/comments/hsq7ep/buzzkil...

It's chinky and not opensource.

I would gladly pay a dollar in the official store to get this app, even knowing it can be downloaded for free from GitHub

I’m not an Android user, but props to you for taking the feedback onboard and doing this, Anuj. Lot of respect for you. In an era of eroded privacy, intrusive notifications, and enshittification you’ve done a genuinely positive and helpful thing to allow ordinary users to fight back.

And, yes, some people will criticise code quality but (a) if those people aren’t actively contributing to the product then you should ignore them, and (b) I suspect the complainers will largely be drowned out by the many who will support your decision.

You certainly aren’t the only highly experienced engineer vibe-coding their way through a problem - I’m leaning very heavily on Claude, and somewhat on ChatGPT, at the startup I’m working on at the moment.

Thank you, Anuj!

You're very kind, thank you!

I would pay a lot to have this on iPhone as I'm distracted easily due to my ADHD. iOS doesn't have as granular notification configuration as Android (topics?) plus Apple probably wouldn't agree to funnel all notification through 3rd party app.

This is what drove me to uninstall Facebook, twitter, etc. I use their websites if I occasionally want to visit. I don't want notifications hooking me into my phone.

You're right - the app sandbox model in iOS prevents inter-app communication of notifications, and there is no iOS equivalent to the Android ListenerNotificationService API.

For me the biggest pain was email.

I created a free and open source set of filters to fix this. Soooo much better.

https://unfuck.email

This addresses email notifications only. There is a lot of apps that would send you notifications that you want to see like your hardware needs attention but also sends some useless promo notifications

Kudos on open-sourcing!

Happy to see this! :)

Hope I find time to contribute :)

I'm surprised Android has an API for one app to block notifications from other apps. I guess enjoy it while it lasts.

The NotificationListenerService.

It has genuine use-cases such as this DoNotNotify app, but could easily be misused - e.g. malware intercepting a wallet OTP notification and forwarding it to the attacker.

Access to the API is controlled by a specific permission which users have to explicitly enable in "Special app access".

https://developer.android.com/reference/android/service/noti...

Real risk of them blocking or crippling it at some point. They've nerfed a lot of useful things over time, Wi-Fi scanning being one good example.

Another legitimate use case are e.g. Event Reminder, which intercept my calendar notifications and turn them into full screen alarms.

My distracted ADHD brain misses event notifications just too often, but with this app, even I my phone is in another room, I get reminded of that meeting, in time.

Does this by any chance works against built-in applications that don't allow you to disable notifications?

Last week I was configuring Samsung for my mother and it constantly nags her with notification for setting up Samsung account (that's not the worst offender tho) and frankly that would really help here.

It should be able to, unless they are using Live Update [0] notifications.

[0] https://developer.android.com/develop/ui/views/notifications...

Great step!

How do you add rules to the app?

The starting point is a notification from an app that you want to create a rule for. So you wait for a notification, then click on it in the "History" tab, and then you can configure the rest from there. It's slightly non-intuitive, but the reason for that flow is that the app needs the package name of the app, which almost nobody will know.

How does it compare to https://galaxystore.samsung.com/detail/com.samsung.systemui....?

I think that would have been an excellent answer if it didn't come with the first two paragraphs.

I couldn't tell the difference at a glance without being familiar with both apps.

As is said, not trying to rude or sarcastic or anything.

I do not use any of the apps and just had a short look at the respective pages to see what they are. Both clearly state the repsective apps purpose, both have images of the apps.

I thought it was (in both cases) pretty clear what the respexctive app is and what not.

I started doing all my projects as open source from the beginning The problem isn’t “well then they won’t pay” there tons of coders and open source users who would gladly save time and energy with paid hosted version this is what I offer potential customers that’s not even the hard part the hard part is and always will be marketing and sales and distribution

This isn't really a commercial project, so not much of that applies.

You should still add an IAP to the Play Store build, and make it "paid" even if it has no different features. There are dozens of us who support OSS apps, dozens!