就是没有硬件可用。不要说软件适配，开发团队都买不到实际可用的硬件。arm 的服务器一直处于 experimental 阶段，只有少数云厂商、小型开发板，以及国内为了政治指标硬上的电子垃圾等少数产品能用到 arm 的服务器。

只允许 53 那你只能自己搞一个 dns tunnel

@simpsonamanda902 #13 直接跟他们说合法用途啊，steam 上不去，Windows update 无法更新等，要求装维检查维修。

telegram 安全和隐私都不是最好的，但是是性能最好的。

如果你要三个平台都 native ，那你只能真的用 native ，或者 native 封装的方式。
如果是用 web 模仿 native 样式的话，你只能选一个平台的模仿，除非你给多个平台写多套 ui 。
参考 https://github.com/virtualvivek/react-windows-ui

@lisongeee #47 恶意版本的分发倒是和开源闭源关系不大，主要是考虑到直接联网更 vulnerable 。一是小白订阅到恶意规则，二是如果不联网那么添加网络权限的恶意版本会更易辨别。
如果被墙和干扰的问题能解决，那倒是好很多。不过考虑到以后可能要规避风险，规则订阅只能以 unofficial 的方式提供，添加一些诸如 diff view 等便于用户 review 规则的功能还是有必要的。

@lisongeee
关于上架，可以上架 Google play fdroid 等海外商店，但还是那个问题，因为墙和干扰的缘故，大部分小白用户还是要依赖网盘群组等非官方渠道传播。

@lisongeee
不是不信任你，而是攻击面的问题，开发一个特权程序的同时要考虑防止程序被 exploit 。
因为不能上架，官方发布地址和订阅地址会被墙或干扰，在多小白用户中会通过群组/网盘等渠道传播。
这样有人 host 一个第三方的规则订阅源，然后可以偷偷添加如社交媒体自动关注点赞转发等操作。而让用户手动导入本身也会鼓励用户 review 他要导入的内容。同理如果不直接联网，第三方渠道传播的恶意打包版本也更容易让用户警觉。
另外介于里跳跳的前车之鉴，应该从最开始就考虑规避风险的问题。建议把规则仓库下掉，另开一个“community”账户维护规则，两个仓库相互声明没有关联，所有操作用户负责之类的。

@lisongeee #17 规则更新需要非常频繁吗？如果实时性要求没那么高，可以内置到 apk 里定期 release ，或者让用户从文件/剪切板导入。
倒不是开源的问题，而是最小化权限原则。里跳跳被很多人信任也是因为静态规则。使用下来感觉这些规则并不需要一直频繁更新，第三方应用的变更并不多，所以未必需要引入在线订阅这种适用于非常动态的场景。

特权应用最好不要直接联网

云主机就别想了，自己搭建的 kvm 可以调一些参数让 Windows 虚拟机可以使用 hyperv ，从而运行 dockerdesktop wsl wsa sandbox 等应用。

https://source.android.com/docs/core/architecture/partitions
“底包“一般指刷写 system 分区以外的其他分区的镜像。一般第三方 ROM 是替换 system 分区，部分包括 boot （内核）和 recovery 分区，其余分区则是来自原厂。部分刷机包会包含经过 ROM 开发者测试过的版本的 vendor/product 等原厂分区镜像。

以前用过，自从这个工具转向云服务集成的方向就弃用了。