Make System Updater notifications “fixed”, with the REBOOT channel configured as non-blockable.

[haok1402]

Description:

This PR improves System Updater behavior by making its notifications “fixed” and marking only the REBOOT notification channel as non-blockable. This prevents users who intend to silence some notifications from accidentally disabling the critical notification that the system must be rebooted to install a pending update..

This approach follows the model used in other system apps (e.g. GmsCompat), where notifications are fixed but individual channels can still be selectively disabled — except for the critical ones.

Changes:

• System Updater is statically granted the ability to post “fixed” notifications via /etc/default-permissions/app.seamlessupdate.client.xml, so users can disable only blockable notifications.
• The REBOOT notification channel is marked as non-blockable.
• All other channels remain explicitly blockable, allowing users to silence non-critical notifications.

Testing:

Tested on Pixel 6a with 2025052000 release to ensure:

• Reboot notification remains active and cannot be disabled.
• Progress and up-to-date notifications can be turned off by the user.
• No regressions or changes in expected update behavior.

A screenshot of the System Updater notification settings demonstrating these blockable channels can be found here: https://drive.google.com/file/d/1bbqeMaGjaT-LQj5_H0TXzv2CbUk85VVi/view?usp=drive_link

Additionally, a recording showing a user explicitly disabling the up-to-date notification is available here: https://drive.google.com/file/d/10RXgOeVZSo-7ZayeQdJeKu1yF0Zs8kZY/view?usp=drive_link

Expected Behavior:

• Reboot alerts are always delivered to ensure required action is taken.
• Users can still disable non-critical update notifications like the download progress.

These notification changes may make the alert behavior in #102 unnecessary, since users will no longer be able to disable the reboot notification. However, I believe the alerts about mismatched networks proposed in #105 remain relevant even if #102 is superseded by this PR.

Resolves: #101, #102

I am happy to revise and resubmit the code if any changes are desired.

[thestinger]

@haok1402 This had to be reverted due to causing an unusual behavior where some users who previously modified a channel can't modify any of the channel settings anymore. This shouldn't be the case because whether a channel is blockable is configurable. Going to be doing another release without it included for now. In order for it to be included, the reason for it causing this issue for several users will need to be identified and solved.

[thestinger]

@haok1402 We think your change is completely correct. The issue seems to be caused by an OS bug or intended but unexpected behavior resulting in strange behavior for a priv_app using fixed notifications.

[haok1402]

Thanks for the follow-up and the extra context — really appreciate it. Glad to hear the approach itself seems sound. I didn’t expect it to cause that kind of behavior with the channel settings, especially since I was able to toggle them on and off multiple times during testing without any issues.

@thestinger Would you happen to know of any priv_app-related code or system components I could look into to better understand what might be causing this? Happy to dig deeper and see if I can help narrow it down.

[thestinger]

@haok1402 The issue is likely a problem with this code in the Settings app or something it uses:

https://github.com/GrapheneOS/platform_packages_apps_Settings/blob/d4ee8a48c3ccf3112fc6b42bc8499aaa2de0cabe/src/com/android/settings/notification/app/NotificationPreferenceController.java

[haok1402]

I ran two incremental-OTA update paths on Pixel 6a, from 2025052000 to 2025060100, and an older one from 2024010400. For each path I first (a) disabled one of the System Updater notification channel and, in a separate run, (b) disabled the app‑level notification switch entirely.  After the update completed and the device rebooted, the prior states on channels other than REBOOT got preserved, and can be toggled. For REBOOT, regardless of its prior states, it was overridden to be ON, and can't be switched off. As a result, I'm unable to reproduce the reported regression on this device. It would be helpful if we can obtain the prior release or device model where the issue occurs.

[inthewaves]

Issue apparently can happen if the Updater is set to only run on certain conditions. Previous version of Updater only did NotificationChannel creation in the Service#onCreate method, but the Service can be prevented from starting due to various conditions (if user configured charging required, or internet not present, etc.). If the Service doesn't run, the NotificationChannels never get the setBlockable calls

#118 reapplies this PR with conflict fixes; it's not clear if there's any other bugs in the OS code around this