@little_cup 个人推测这个功能应该是用 NotificationListenerService.getNotificationChannels 实现的
https://developer.android.com/reference/android/service/notification/NotificationListenerService#getNotificationChannels(java.lang.String,%20android.os.UserHandle)
文档里面有提到“The caller must have device”，而 AutoNotification 在首次使用时也会要求选择一个设备。

@ariera 我前面说了 AutoNotification 呀，你看看我刚才发的截图。

@little_cup 测试截图出来了
首先直接打开热点是会出现通知的，且能看到通知上有铃铛图标，代表会发出声音
https://i.v2ex.co/Aix70lBJ.jpeg
在系统的通知设置中也能看到开关是灰色的，不可关闭
https://i.v2ex.co/y67B46WO.jpeg
授予 AutoNotification 通知访问权限，然后选择对应的渠道
https://i.v2ex.co/qq6QjyjH.jpeg
把重要程度设置成 Low ，此时状态栏上的图标消失，通知上的铃铛图标也消失
https://i.v2ex.co/4j6Kf4uJ.jpeg
https://i.v2ex.co/IhrQLOjW.jpeg
取消 AutoNotification 的通知使用权，并且用冰箱冻结，在系统设置中仍然可以看到对应的通知是关闭状态，且开启热点也不会出现对应通知
https://i.v2ex.co/JNL0h34I.jpeg
https://i.v2ex.co/kRjyGQT5.jpeg

之所以不想用 AutoNotification 是觉得界面太难看，通知滤盒已经有了很好看的界面，希望能在此基础上加上此功能，这个功能不仅仅是为了过滤通知，还能设置震动规律，以及通知指示 LED 灯的颜色(需要 LED 硬件支持 RGB)。如果开发者觉得加入这个功能后可能导致很多人不付钱设置完就卸载，可以做成付费专用功能。

@little_cup 但是实际不需要 root ，用 AutoNotification 通过通知访问权限就能实现。

@little_cup #13 这是在回复我吗？如果修改通知设置后，用户卸载了应用，那还可以用系统的设置 app 把对应通知给启用。
我想要的功能是能直接修改系统的通知设置，我不需要根据通知内容进行某些操作，我只需要能修改系统的通知设置，比如禁用通知、设置优先级、是否在锁屏显示，因为 MIUI 把相关选项给砍掉了。我不希望后台有个程序持续处理通知。

@little_cup 不是 Pixel ，有空我做个测试截图看看吧。

同时 AutoNotification 修改通知设置后，在系统设置里面也能看到改动，关闭系统应用的通知后，系统设置中对应项目能看到也关闭了，且开关不是禁用状态。

@little_cup 你确定吗？ AutoNotification 修改设置后再取消授权通知访问权限，并且停用 AutoNotification 仍然有效。但据我所知通知滤盒必须持续运行才有效。

不需要理由的

@nekoneko 印象中 T4 性能很差的吧？好像连 RTX2080 都比不上。

直接 mmap 吧

可以用 AutoNotification 修改通知设置，需要先授予通知访问权限，修改后即可取消授权，改动是保存到系统中的，不需要相关应用持续运行。这个方法可以修改系统应用的通知设置，即使设置里是灰色的。
不过 AutoNotification 收费，不想付费的话需要看广告，然后能免费使用 24 小时。

这个问题是小米的锅，因为 MIUI 一些旧机型的 Android 版本是旧的，所以小米把通知设置里老版本不支持的选项去掉了，结果导致用户没法设置一些选项。

@little_cup 希望能给通知滤盒加入上述功能，我愿意为此付费。

@nothingistrue 本主题讨论的是跨应用文件保护问题，Android 难道保证不了应用数据安全的问题吗？ Android 的其他权限，如录音、录像、录屏权限能绕过吗？
UWP 可以不适配移动端，但微软这种设计显然是想开发者自动适配移动端，因为 UWP 中桌面独有的 API 很少，很多界面元素也是为触屏设计的，开发者写一个桌面应用，很容易甚至无需改动就能在移动端上运行。
我说 Win32 API 被砍指的是 UWP 应用中被砍了，隔壁 macOS 应用仍然可以调用 POSIX API 去打开文件，去启动新进程，但 UWP 应用给吗？甚至反过来，一个非 UWP 的 Win32 应用想使用 UWP 的 XAML UI ，在很长一段时间都是不可行的，直到微软推出了 Xaml Island 。隔壁 macOS 新旧 API 都兼容，也不见怎么失败。所以我说 UWP 失败的原因是它一刀切，而一刀切的原因是要强迫开发者开发出来的应用能自动兼容移动端，因为如果不砍掉旧的 API ，开发者们就会像 macOS 那样新旧 API 混用，享受新 API 带来的爽的开发体验的同时不给移动端做半点贡献。
微软曾经也做过类似的事情，Windows Vista 时代，一些操作系统已经开始提供丰富好用的 API 了，比如 macOS 的 Cocoa ，当时传言微软要把.NET 做成 Windows 的基础部分，结果 Vista 发布后大家发现.NET 仅仅是随系统附带了，没有与系统深度集成，Windows 中并没有多少应用是使用.NET 开发的。微软甚至不给.NET 提供 Win32 API 的声明，想用.NET 调用底层 API 的话还得自己参照文档写声明，虽然.NET 加入了 WPF 这个全新的界面库，但是整个.NET 整得像是个二等公民，像是独立的岛屿。微软自己在 Vista 中加入了一套私有的界面库，但是却不肯公开出来，言下之意是你想开发得爽就去用我们的.NET 和 WPF 吧，给我们的.NET 做贡献。这个操作可以说是进一步推动了 Windows 开发框架的碎片化。

@nothingistrue 应用级权限管理并不等于封闭，Android 也在用这种模式，你觉得它封闭吗？
macOS 也不是非常封闭，至少是有 root 权限，以及允许加载内核扩展的。
UWP 的失败不能说明应用级的权限管理是失败的，相反，我认为 UWP 在桌面 Windows 失败是因为微软一刀切。macOS 在引入新 API 时仍然保留了传统好用的 POSIX API ，同时 macOS 和 iOS 的 API 不是完全通用的，而是根据桌面端和移动端不同的应用场景、界面操作做了区分的。而 UWP 则是一刀切强行统一桌面端和移动端，把桌面端传统好用的 Win32 API 直接砍掉，我认为微软此举是通过限制 API 能力来让开发者“自动”为其移动端进行开发，这才是开发者用脚投票拒绝在桌面平台使用 UWP 的原因。以微软的能力完全可以实现传统与现代 API 混合、权限逐步收紧，渐进式地进行更新。

@Asakijz#6 电源功率选择可以参考前面提到的视频，后面有讲。
#12 这种叫做整机，总体来说坑比较多，如果一定要买的话建议选择在视频网站运营、口碑好、曝光度高的整机商。

推荐看看 https://b23.tv/BV1bT411M7zd

调系统 API 。
Linux 下可能比较麻烦，因为有很多种网络管理器。NetworkManager 的话比较简单，用 D-Bus 接口即可。

@hez2010 现在的问题就是 Windows Credential Manager 没有只允许某一应用访问的功能。

个人认为主要问题还是操作系统没有提供应用级的权限管理，目前三大桌面操作系统中只有 macOS 默认有应用级的权限管理。