@hyshuang2006
FCC 不会测试美国不使用的频段。

pixel2 会和 pixel1 一样同时提供北美版和 row 版本，row 版会完整支持电信以外的内地 lte 网络，北美版类似但不会支持频段 38 ～ 40 并且会缺失一些载波聚合的支持。volte 支持可能依然缺失。

首先需要到 mozilla 进行根证书收录申请工作，这部分成功后再向 google，microsoft 等进行申请。mozilla 方面的成功申请可能是一个前提条件。

ap 可以用 tp-link 的 86 面板式（ 802.11ac ） ap （一个 ap 大概 350，设置成可单独控制无需 ac 的 fat ap 模式）的方案，它还做了 iptv 用的直通网口口

ubiquiti 的 unifi 也很好，就是价格高

lg watch，但是满足不了楼主的 1，2，3，4

@ericgui 这件事情让你无奈地发现，国产软件真的是不能碰

@mikicomo

这种应该是软件方面的问题（硬件驱动，基带部分的操作系统等）

@WalkingEraser
我能确定 6p，pixel 几十天不重启一般没事

@thinks 做到你们这样非常熟悉的时候区别就小了，什么头都能很轻松地打好

@vitalbo 用那种分成两个部分的水晶头好做一些，先把线穿到小的那个配线器，剪好，再塞到水晶头里，这样的话其实比普通的五类头简单。直插的就困难了。

还有更困难的 6a 屏蔽头，还需要屏蔽线和屏蔽壳良好接触，又要能把比 6 类更粗的线塞进网线头，我做过三五个，全失败了。

在中国做到完全不用百度产品不是很简单吗？

难的是 bat 三者，以及它们控制的都同时不用。
我吹嘘不用它们，但在 at 方面也只能部分地做到（比如支付宝不使用移动端，快捷支付，仅通过网银付款）。

换 hyper v 或者 vmware，前者有一个技术可以调用主机的显卡

比较少喝速溶以外的

我们都知道这样是错的，但是，反对无效

用 appops 把它的 RUN_IN_BACKGROUND 项目设置为 ignore，可以有效抑制这个问题
最终解决办法还是要靠注销 service 或通过 IFW(绿色守护的处方特性)阻止 service 被唤醒

@allinwonder
@yunkchen
@cxyfreedom
总之 windows 的换行符是先回车再换行
linux 只有回车，mac 只有换行

@Chingim 免费提供的 vmplayer?

@standin000

根据
https://android.googlesource.com/platform/frameworks/base/+/bef28feba57be7fd6a4d14a85a8229154338b2ed%5E%21/

有 Android 7+ 的话，AppOps 的 RUN_IN_BACKGROUND 确定能对付这个问题
“ All jobs for the app are cancelled and no more can be scheduled.”

使用 AppOps 无需 root，只要有 adb 就可以用

这些软件把 adb 模式给包装好了:
https://www.coolapk.com/apk/com.zzzmode.appopsx
https://www.coolapk.com/apk/rikka.appops


如果没有 Android7+，就要有 root 权限，可以使用这些方法：

通过 pm disable 注销 KeepAliveJobService
具体：
https://www.coolapk.com/apk/cn.wq.myandroidtools

通过增加一项 IFW 的规则阻止 KeepAliveJobService 被调用
具体：
绿色守护的处方特性

强制把应用设置为 app standby
具体：
绿色守护改用 shallow hibernate 模式(这个可能没意义，你终究是希望把它的 service 杀掉，进程可以保留)


如果没有 Android7，也没有 root，那就要用 brevent，它会混合使用 app standby+FC，效果至少比绿色守护好一些

Sync/Job 的话仅仅是系统进入任何一级的 doze/应用被 app standby 就会被推迟到下一个维护窗口

@standin000

绿色守护的作者在 bugreport 列出了一些常见的保活措施:
https://issuetracker.google.com/issues/62480012

"
1. Restart the service with a frequent periodic alarm (less than 5 minutes), causing the service being stopped and started again and again. (same applied to JobScheduler and SyncAdapter)
2. Restart the service inside its Service.onDestroy(), reviving the service immediately upon stopping.
3. Raise the background service to foreground service, when the screen is off to dodge from observation by user.
4. Bind to each other within 2 services, to fool the activity manager to consider them as bound services.
5. Restart service from JNI native library with "am start-service".
"

我觉得比较可能是通过另一个应用的 SDK 发出 expilcit Intent 启动，或者 Sync/Job 的方式，它们都能绕过 Force Close
有 Android 7 的话，RUN_IN_BACKGROUND 应该能对付这里的所有情况
然而如这个 bug report 所说，7~7.1 的这个实现有 bug(直到 Android 8 DP4 修复)，只会杀进程的第一个 service