Target Android O about revolution-irc

[MCMrARM]

Telegram on Android implemented this somehow. It seems like you're simply capped by your notification settings, and you can simply request the most extreme options to be able to modify them as you want for particular notifications.

[19lmyers]

To my knowledge you can modify notification channels if you use the same ID to create it. I might have incorrect information though.

Uninstalling an app also resets the notification channels it has created.

Android P also adds notification channel groups, which could mitigate some of your concerns.

[MCMrARM]

You can not. That's wrong.

Yeah, uninstalling works. Also, clearing data manually works, but you can't do it with revo as I have my own storage management menu.

Notification channel groups don't help here.

Telegram on Android simply creates a new channel every time you change the settings. That's what I will do when I'll have to target O later this year.

[19lmyers]

But why do you need to create a new channel every time? That seems illogical.

On Thu, Jun 21, 2018, 8:29 AM MCMrARM ***@***.***> wrote: You can not. That's wrong. Yeah, uninstalling works. Also, clearing data manually works, but you can't do it with revo as I have my own storage management menu. Notification channel groups don't help here. Telegram on Android simply creates a new channel every time you change the settings. That's what I will do when I'll have to target O later this year. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANsrXyLdeBjmWy8KJ0HEE1Gv0UlRcT40ks5t-7vTgaJpZM4PsnWH> .

-- Sent from Inbox

[MCMrARM]

Because Android is broken. That is the real answer. The broken API for notification channels does not let me edit them.

[19lmyers]

Android is not broken. If it was, Google would do something about it. Everythibg in Android for good or bad is by design. I'm using notification channels fine in my app. Why do you need to edit them so badly?

…

---------- Forwarded message --------- From: MCMrARM <[email protected]> Date: Fri, Jun 22, 2018, 6:07 AM Subject: Re: [MCMrARM/revolution-irc] Target Android O (#9) To: MCMrARM/revolution-irc <[email protected]> Cc: Luke Myers <[email protected]>, Comment <[email protected]> Because Android is broken. That is the real answer. The broken API for notification channels does not let me edit them. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANsrXyx08PE7A_cGyjfCyKxy-KJNRVrjks5t_OwbgaJpZM4PsnWH> . -- Sent from Inbox

[MCMrARM]

Google's idea was to have the user be sent to their settings. However, not all settings can be edited there (e.g. sound, vibration length, led color).

The API is certainly broken and badly thought-of. There's nothing stopping malicious apps from creating a new channel for every notification. However, the notifications settings are incomplete and the API is being too restrictive for devs that let the users control the notifications within their own app or want to add additional features.

[19lmyers]

I'm really not sure why that means it's "broken." Sound CAN be edited there, but the others aren't supposed to be available in stock at all. Apps can provide additional settings in addition to the system notification channel settings. Nobody else has complained about notification channels, and frankly, I don't see why you have any reason to. It's not a barrier preventing you from doing anything.

On Sat, Jun 23, 2018, 8:11 AM MCMrARM ***@***.***> wrote: Google's idea was to have the user be sent to their settings. However, not all settings can be edited there (e.g. sound, vibration length, led color). The API is certainly broken and badly thought-of. There's nothing stopping malicious apps from creating a new channel for every notification. However, the notifications settings are incomplete and the API is being too restrictive for devs that let the users control the notifications within their own app or want to add additional features. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANsrX7e172FQxEsujIXeyPbM7X76Wgy2ks5t_lqygaJpZM4PsnWH> .

-- Sent from Inbox

[MCMrARM]

Apps can provide additional settings in addition to the
system notification channel settings.

You can not provide those settings, because you can not edit the channels from the app. That's my problem.

[19lmyers]

You don't need to edit the channels to provide those settings. You store them in a SharedPreference and use them when creating your notification.

On Mon, Jun 25, 2018, 11:29 AM MCMrARM ***@***.***> wrote: Apps can provide additional settings in addition to the system notification channel settings. You can not provide those settings, because you can not edit the channels from the app. That's my problem. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANsrX0jnfb9STH8s8B04NhmlNk6flxNBks5uASwigaJpZM4PsnWH> .

-- Sent from Inbox

[MCMrARM]

You can not. If you could that would be fine. But the notification channel settings override any settings you set. My previous sentence about them "upper-bounding" your settings was wrong - they just override them. I tracked it down in the AOSP source tree some time ago, if you want to look into it yourself, I can track it down again.

[19lmyers]

It's their job to override certain settings. But the others you mentioned, like LED color, aren't touched by notification channels.

On Mon, Jun 25, 2018, 1:32 PM MCMrARM ***@***.***> wrote: You can not. If you could that would be fine. But the notification channel settings override any settings you set. My previous sentence about them "upper-bounding" your settings was wrong - they just override them. I tracked it down in the AOSP source tree some time ago, if you want to look into it yourself, I can track it down again. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANsrX8WqbhHQZ3Bt-Vc5vyGecd2r-tLWks5uAUjegaJpZM4PsnWH> .

-- Sent from Inbox

[MCMrARM]

Having to edit half the settings in one place and the other half in another place would truly suck as it's a truly terrible UX experience.

By the way, you seem to be wrong and LED color is NOT override-able outside the channel, see: https://github.com/aosp-mirror/platform_frameworks_base/blob/master/services/core/java/com/android/server/notification/NotificationRecord.java#L216

[19lmyers]

That's interesting. I'll debate the "bad UX" claim though - most apps don't give notification settings in the first place. I also still think your perceived need to continually recreate notification channels is a problem with your UX, not Google's But you're going to have to target Oreo eventually due to Play Store guidelines...

On Mon, Jun 25, 2018, 1:42 PM MCMrARM ***@***.***> wrote: Having to edit half the settings in one place and the other half in another place would truly suck as it's a truly terrible UX experience. By the way, you seem to be wrong and LED color is NOT override-able outside the channel, see: https://github.com/aosp-mirror/platform_frameworks_base/blob/master/services/core/java/com/android/server/notification/NotificationRecord.java#L216 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANsrX7HepHsiqUj3obnP9rMpwjU-C1FXks5uAUsrgaJpZM4PsnWH> .

-- Sent from Inbox

[MCMrARM]

Yeah, I don't see anything wrong with having the settings there. It is a good idea and change. I DO however see a problem with locking devs from modifying the channels themselves. That's why I claim the API is broken.

???? I do not get what you mean. "your
perceived need to continually recreate notification channels is a problem
with your UX, not Google's" - UX is User Experience, as in how the UI works out for the user. It'd be an inconvenience to have to change half the settings in one screen, and the other half in another one. That's what I meant.

Having to create a new channel every time is basically a workaround for the not-too-well-thought API Google made. The only other option to let me edit the channels is to request full Notification access permissions, which is worse, because it raises more trust issues.

[19lmyers]

Why do you need to edit the channels in the first place?? If you need to use a dirty workaround, the problem is on your end. Nobody else has had a problem with the notification channel APIs, otherwise I would have heard of it by now.

On Mon, Jun 25, 2018, 1:50 PM MCMrARM ***@***.***> wrote: Yeah, I don't see anything wrong with having the settings there. It is a good idea and change. I DO however see a problem with locking devs from modifying the channels themselves. That's why I claim the API is broken. ???? I do not get what you mean. "your perceived need to continually recreate notification channels is a problem with your UX, not Google's" - UX is User Experience, as in how the UI works out for the user. It'd be an inconvenience to have to change half the settings in one screen, and the other half in another one. That's what I meant. Having to create a new channel every time is basically a workaround for the not-too-well-thought designed API Google made. The only other option to let me edit the channels is to request full Notification access permissions, which is worse, because it raises more trust issues. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANsrXx0-pPjX58wkxm16YO2vb4QabMZmks5uAU0JgaJpZM4PsnWH> .

-- Sent from Inbox

[MCMrARM]

You do not necessarily have to hear of every single issue a developer can have. Most of the Android devs just work around and not complain, as if Android dev teaches you anything, it is that you can never trust the platform not to be buggy and that you'll often need to hack your path through.

As I said, I want to edit the channels so that I can:
a) which I have pointed at least twice now, let the user change misc settings, like custom notification sound, vibration length, led color, etc.
b) have the settings nicely composed into the settings of mine, which is not super-important, but negatively impacts the UX

[19lmyers]

a) does seem like an oversight on the part of Google, but b) is against Google's recommended guidelines for notification settings. The Material docs recommend linking to the notification channel's settings from your settings, and advise against duplicating information.

On Mon, Jun 25, 2018, 2:05 PM MCMrARM ***@***.***> wrote: You do not necessarily have to hear of every single issue a developer can have. Most of the Android devs just work around and not complain, as if Android dev teaches you anything, it is that you can never trust the platform not to be buggy and that you'll often need to hack your path through. As I said, I want to edit the channels so that I can: a) which I have pointed at least twice now, let the user change misc settings, like custom notification sound, vibration length, led color, etc. b) have the settings nicely composed into the settings of mine, which is not super-important, but negatively impacts the UX — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANsrXx-mKbxWtnXn-UW11R85YzxE8BFzks5uAVClgaJpZM4PsnWH> .

-- Sent from Inbox

[MCMrARM]

a) YEAH THAT IS WHAT I MEAN ALL THE TIME
I'm not going to delete those settings ffs. And it doesn't even make sense for me to.
b)

The Material docs recommend linking to the notification channel's settings

lol what. Material is a design, not a set of guidelines for Android. Unless it changed. But that'd not make the slightest sense.

Also, the 'create new notification channel every time' is being done by at least Telegram and looking at Google, also What's App. Neither Signal nor Line did update to the new API level.

[MCMrARM]

Also, as for guidelines. It's guidelines, as in the clues you should follow in most of the cases. However, if you have got a good reason to, it's alright to make an exception. I believe in this case, in-app notification settings are fully fine.

[ann4belle]

"Material Design" is the name for a set of guidelines that, when followed, produce a uniform look across different apps. Yes, you can go against them, but don't expect Google to bend over backwards to support you if you do. The reason they want people to be directed to the Settings app instead of having every developer make up their own way to edit notifications is because it makes far more sense to the average user, which is primarily who the Android devs are thinking about when they design and build Android.

I assume that the reason the API doesn't allow you to edit notification channels programmatically is twofold: to encourage developers to follow the Material Design guidelines, and to prevent apps from changing the notification priority of their notifications after the user has edited them. It's likely easier (and less prone to exploitation, thus requiring less edits down the road) to simply disallow apps from editing channels entirely rather than allowing them to edit some fields but not others.

Why they don't allow the user to change the LED color or vibration pattern is a mystery to me, but it could be so that Settings doesn't have to worry about what (if any) alternate LED colors the phone supports/what vibration patterns the user has created, or it could simply be because not enough people care about those features to bother implementing them.

[MCMrARM]

"Material Design" is the name for a set of guidelines that, when followed, produce a uniform look across different apps.

"Material Design" sounds like a set of design guidelines, not like the set of guidelines which Android apps should follow. I remember there being a few hints about how apps may want to do some things in the specs, but they still do not belong to the design, at least in my opinion.

The reason they want people to be directed to the Settings app instead of having every developer make up their own way to edit notifications is because it makes far more sense to the average user, which is primarily who the Android devs are thinking about when they design and build Android.

Imo the main motivation for this was that developers did not add any sort of settings and it was one huge mess for the user, as well as let the user easily set the priority of some notifications to a lower value from the notification bar. This is alright, however then they figured out it might be nice not to have two sets of settings (one in the app, one in Android settings) to avoid confusion, so they told developers to kill off their settings. It does make sense, for the majority of the apps. However, this idea is broken:
a) Because there is no way for developers to add extra settings. In my case, I need to add settings that affect which channels are affected by the specific notification rule. This cannot be done in this system, and it's a shame as splitting a single screen into two is always bad.
b) The settings Google provides are incomplete. This is probably because they figured out basically no user will need to edit stuff like LED color of a pre-defined notification channel, and the app shouldn't need to edit it either, assuming the color is application-provided. Additionally, it is possible to make a third-party app to let the user change these settings (apps with notification access can edit any notification channels). In the case of my app however, the user sets the color, as therefore he can want to switch it at any time, and I don't want to request permission to access the user notifications just for that, nor send him to a third party app.

This preferably should be done the way how Storage Management is handled. Provide a default settings interface, and let the developers replace it. Unfortunately, it seems this change hasn't hit any of Google applications hard enough for them to consider adding a backdoor like this, so we're stuck without it.

It's likely easier (and less prone to exploitation, thus requiring less edits down the road) to simply disallow apps from editing channels entirely rather than allowing them to edit some fields but not others.

Making only some settings editable wouldn't make any sense. Then noone would be able to find the missing settings anywhere, and would 'wtf' at the split as soon as they notice it. I wouldn't call it a solution of any sort.

I'll be implementing this using the hack I mentioned earlier later this year, when Google will start requiring the O API level targetting, and this is what several other apps already do.

[MCMrARM]

Fixed with a79edd0

The final implementation is as follows:

• A separate channel is created per each notification channel rule with a random UUID as the ID. This channel can freely be edited from the Android changes, and the application fully respect them.
• The application keeps its own notification settings, with Sound, Vibration and LED color possible to change. When the user changes them, the old channel is deleted, and a new one with the changes created. Note that some user settings may be lost when the user changes them, perhaps this could be improved. A link to the Android settings is also added at the bottom.