@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 默认有应用级的权限管理。

推荐看看 https://zhuanlan.zhihu.com/p/442083333

我选择 nginx 的 WebDAV 插件，虽然要折腾一下配置文件以解决一些客户端的兼容性，但是性能还是不错的。
曾经用过一个 Golang 写的 WebDAV ，aria2 多线程下载很容易占满 CPU ，有的时候还会出现暂停下载后不响应新的请求，同时仍然占用 CPU 的问题。
没用过 rclone ，不确定性能如何，楼主有兴趣的话可以对比测试看看。

中文语境下的“开源”含义已经变成了“公开源代码”，即使使用有很多很严格限制的协议都能被称作开源。