@0o0O0o0O0o 常见于快递配送外卖送餐等行业，安全性自己取舍。

国内有一些 5500mAh 以上的机器，优化可能不行。三星有 7000mAh 的机器，不过没国行，国内能用的频段太少，信号堪忧。我建议 B 站或者某宝搜魔改电池。

@0o0O0o0O0o 预防性补充：
- “可我很少用相机啊”
- 可苹果发布会最大的篇幅就是摄影啊

表演一下什么叫绝望：排队很久终于排到人工客服，客服说，麻烦您拍个 xx 角度的照片。

说别人不懂后台机制的不知道用没用过 12G/16G 的安卓机器？

@0o0O0o0O0o 看了正文才知道是备份删除的文件

USN Journal

@0o0O0o0O0o 特指 Android 端

关于天花板这个说法，我觉得，难度上其实还不算，薪资上不好说，风险上算。

我觉得吧，想让 lighting 换成 Type-C，起码要先确保 Apple 不会砍掉有线吧；想要 Apple 不会砍掉有线，则要用户追求快充的呼声够高。否则就 Apple 现在这个有线快充水平以及用户群体对它的容忍度，真的如楼上几位说的，它砍掉有线大力发展无线可能性太大了，它的无线只要拉到 Android 旗舰水平，都比它现在的有线快了。

@imcczy
@0o0O0o0O0o #14

其实我也知道 arm+kvm 是上限很高的方案，x86 转译太容易被检测，只是我目前没有找到很成熟的方案或者产品，如果是我接触的局限，你可以推荐一下，我一直很向往云手机。。。

@imcczy #12

houdini 是市面模拟器主流方案吧？ bug 虽然有，但我觉得目前是比 Google 那个 arm translation 好太多了，缺点只是 Android 版本低。

我的体验是：

arm 的云手机（也包括你说的自己跑 qemu+aosp ）才是真的难搞，那些做黑产的专项优化的云手机我不清楚，但我个人能买到的或者 github 能找到的此类方案，大部分适配真的成问题。比如 aws 上的 genymotion cloud arm，闪退率惊人，没有仔细研究，看日志大概都是有些东西没模拟全，还不如它的 x86 版本+libhoudini 。。。

而 anbox 的主要优势我觉得在于 lxc 和开源，论兼容（此处兼容和传统意义上的兼容有些不一样，要包括反检测）和商业模拟器是没法比的，它也不在意这一点，跑楼主的需求，会需要写大量的反检测。

https://www.genymotion.com/blog/just-launched-arm-native-android-in-the-cloud-environment-on-aws/

因为就是不支持，常用模拟器已经一些极少数的 x86 设备靠的是 libhoudini，Google 在较新版本的 android studio 的 emulator 里也提供了类似方案以适配高版本的 Android

https://github.com/geeks-r-us/anbox-playstore-installer

https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html?m=1

@dLvsYgJ8fiP8TGYU 这篇文章，是想靠拦截这些 app 的启动或者关闭时的请求来躲避被画像？至少文章列的 X 信 XX 宝 X 团，要么永远别安装和使用，否则这个做法没有任何作用的

@Livid 是两年多的活跃账号了，太苛刻了啊，而且是中途改变的规则。

就算水深火热改变了规则，可举例的主题还有例如这种 /t/788422，被账号新旧影响的理由是什么呢？内容关键字触发的吗？

github 搜 webrtc leak，找个开源插件看看代码，觉得没问题就手动导入插件或者自己写个，也没几行

@yitingbai #110 V2EX 特殊在于这类主题不会被删除，而 google 对于 V2EX 的收录相当快速和优先，搜 “ToDesk 漏洞”已经在第一条，搜 "ToDesk 安全" 也在第一页靠前，所以官方接下来处理这件事的方式方法其实也很重要

@PUBG98k

真想安全那起码不要暴露到公网，无论是不是 https

我觉得楼主的描述相对普通用户已经相当详细了，我也相信好好沟通的话他也会配合开发者做复现，开发者团队这样的态度很不明智。