We actually did work to make the "site settings action appear. See  Issue 610156 . Should be easy to get rid of the "site settings action"

+1 on removing it! This is also the direction we got from Roma in a meeting earlier this year.

As hacky as it may be, what are your thoughts on having something like NotificationSystemStatusUtil.determineAppNotificationStatus() in the WebAPK? It would be fantastic if we could get insight in notification disable rates for WebAPKs vs. regular Chrome notifications.

We can definitely have something like this in the WebAPK. I am going to punt this task to next week.

It is not very clear in the bug description. This change is part of Sam's desire for a larger change where WebAPKs bypass site settings. For instance, a WebAPK for https://tests.peter.sh/notification-generator/ would ignore site settings for https://tests.peter.sh This larger change sounds complicated and will require a lot of time to figure out how to do properly

I just talked to Sam.

Currently, it is possible to disable WebAPK notifications via Chrome settings. However, we want to guide users to disable notifications via Android settings so we should remove the "Site Settings" action from notifications.

There is one on both the front and the back of the notification

Cool. Just to confirm, users can still get to the WebAPK OS-level notification permissions right? (I think it's long press to get to the back part and tap the app icon.)

Yup. It's pretty visible since M, and possible in settings going back to JB. (See slide: https://docs.google.com/presentation/d/1X6_1YzdnfHkVjmQWqvT8HnhQ4CB09y146w9XLwYFDYE/edit#slide=id.g17f5158747_0_0)

Bumping to P1 since this is marked as launch blocking for WebAPKs. (I'm OK if we want to call this non-launch blocking, but while it is officially marked as blocking it should be P1)

Punting from v0.

Removing myself and adding chowse@ as the Web Platform design contact for input if needed.

Is there any agreement made on this bug? If yes, I will go ahead to remove the site setting on the notification of WebAPK.

I'm also in favor. I don't believe anybody is against this, so if you don't hear anyone object I'd go ahead.

Sounds great. Thanks Owen! A CL is on progress: https://codereview.chromium.org/2826223002/.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4df7199f5d2cafd62bf9c9d016caa341230139ca

commit 4df7199f5d2cafd62bf9c9d016caa341230139ca
Author: hanxi <hanxi@chromium.org>
Date: Fri Apr 28 02:15:25 2017

Hide Chrome actions in notifications shown for WebAPKs

This CL hides the "Site setting" action when notifications are shown by WebAPKs.
The "additional settings in the app" link will be removed from the notification
settings for WebAPKs in the System UI in Android O. Before Android O, the
settings gear to open app-specific settings shown on the rear of a notification
following a long-press will be gone as well.

BUG=654539

Review-Url: https://codereview.chromium.org/2826223002
Cr-Commit-Position: refs/heads/master@{#467843}

[modify] https://crrev.com/4df7199f5d2cafd62bf9c9d016caa341230139ca/chrome/android/java/src/org/chromium/chrome/browser/notifications/CustomNotificationBuilder.java
[modify] https://crrev.com/4df7199f5d2cafd62bf9c9d016caa341230139ca/chrome/android/java/src/org/chromium/chrome/browser/notifications/NotificationPlatformBridge.java
[modify] https://crrev.com/4df7199f5d2cafd62bf9c9d016caa341230139ca/chrome/android/webapk/shell_apk/AndroidManifest.xml
[modify] https://crrev.com/4df7199f5d2cafd62bf9c9d016caa341230139ca/chrome/android/webapk/shell_apk/BUILD.gn
[modify] https://crrev.com/4df7199f5d2cafd62bf9c9d016caa341230139ca/chrome/android/webapk/shell_apk/shell_apk_version.gni
[delete] https://crrev.com/5dad32e367d077bf8b84f1700a6cd00e74a20cc1/chrome/android/webapk/shell_apk/src/org/chromium/webapk/shell_apk/NotificationSettingsLauncherActivity.java

The update to shell_apk_version.gni was reverted due to the revert of CL https://codereview.chromium.org/2845943006/), the version number should be updated in a follow up CL.

This is fixed, right?

Only the first part is fixed, and this bug also involves changes in Chrome's setting, see comment#5.