@mhycy
@k9982874

新国标的那批

@mhycy
小米的不带 USB 的排插还是不错的
公牛的也好

@misaka19000
总之应用 FC 了，总是需要一个外部来源把它拉起来，无论是显式意图还是同步 /Job。
如果应用没被杀光，也可以自己把自己拉起来。

楼主没有清楚地说明它遇到的是哪种情况

@wm5d8b 这是新的 build number 格式

“
PVBB.YYMMDD.bbb.
The P variable is the first letter of the platform release, so it's "O" for Oreo currently. The V is for the vertical, which in all the builds you're worried about will be "P" for primary platform branch. The BB characters represent an alphanumeric code that points to the exact code branch used in the build. For the first Oreo release on the Pixel, this is "R6."

You can probably guess at the purpose of the center YYMMDD block just from the format. It's the date (year, month, day) when the release was branched or synced with the development branch. This might not necessarily be the build date as it's common to reuse the same code for multiple builds without going back to the dev branch. The "bbb" set of characters is simply a number that differentiates between multiple builds with the same date code. The Pixel is on 012 right now.
”

http://www.androidpolice.com/2017/08/22/google-changed-build-number-format-oreo-heres-read/
https://source.android.com/source/build-numbers

MIUI 的开发分支可能有更多的限制应用的工具，估计背后实现可能还是和 IFW 有关

一般来说要用二楼这样让应用不能 /难以运行的方式来解决。
神隐模式有一个隐藏选项，对应用的拉起 /后台运行限制更严格
http://www.miui.com/thread-5904400-1-1.html

有这些情况：

非小米手机 /非小米的 Android 版本：
"已经是确认关闭了应用"
你以为确认关闭，事实上并不是

小米的 Android 版本：
"已经是确认关闭了应用"
MiPush 是系统进程，它可以把应用拉起来

“怎么让已经关闭了的应用不能推送消息”
MiPush 似乎无法禁用，也没有提供“不允许拉起应用”的选项，因此无法做到

@yohanechan
这里分辨安装源依靠的实际上就是楼主提到的
pm install -i 背后的实现

@EricInBj
抓 bugreport 吧

"一直觉得安卓是开放自由的"

这同样意味着应用开发商有能力添加不合理乃至错误的限制。
该手游看上去没有使用 safetyNet 的接口，而是很诚实地如楼主所说，简单地检测了一下安装来源而已。


@EricCartman
“ Netflix 也是，root 后手机会显示不兼容，安装了也没法用”
Netflix 这里使用了 safetyNet attestation API


@Syaoran
"这是应用内付费的应"
它显然只可能支持 play 的 IAP，而国内普遍没有 GMS 且有墙几乎无法使用 play 的服务，不能有效地带来利益。

It is intended behavior

求 issuetracker 的地址

所以你们准备用什么方法说服 Android 组给奥利奥加上关于热点的 MAC(BSSID)/SSID 的限制呢？

@greenskinmonster

“我链接中的那个 App Ops 软件的功能”

目前有两个做得很棒的 appops wrapper，一个是你提到的 rikka appops，还有一个是开源的 appopsX

rikka appops
https://play.google.com/store/apps/details?id=rikka.appops
配合用的 shizuku api
https://play.google.com/store/apps/details?id=moe.shizuku.privileged.api

appopsx
https://play.google.com/store/apps/details?id=com.zzzmode.appopsx
https://github.com/8enet/AppOpsX

这两者说到底都是在用 AppOps

“对于非要 READ_PHONE_STATE 才肯运行...应用只会得到空数据”
除了通过反射取 appops 以外，还有一个绕过方法，就是检测到非 null 时一律当作权限被阻止(有些银行的应用会这么做)，绝大多数包括微信在内的流氓软件们都能用它治疗

@letianqiu

这次非常有意思，正式版居然不在工厂镜像页面发布，说明 Google 自己也对这个 GA 没信心，依然只在 beta 渠道发布，正式渠道则可能采用了非常保守的灰度参数

十月份 pixel 2017 发布的之后不久，会和去年一样推送 Android 8.0 MR1(8.0.1)，这个版本会包含这两个月的各种修正补丁吧

这样挺好
喜欢空格的总是有空格
不喜欢空格的总是没有空格

做好这些以后再吵比较好

我不支持加空格，它可读性好但终究是 workaround

@Moker
三星也这么糟糕了？

@greenskinmonster

是一个勘误，针对这句话
“另外未 root 的话，至少 7.0 系统，App Ops 也可以来限制应用的权限，只是需要 ADB 命令来配合 ”

再具体一些的补充

目前而言，AppOps 的作用大致上是运行时权限的一部分 backend(特别是针对旧 targetSDK 应用)，以及一些非运行时权限，以及其它特性(如对 SDK26 以前的应用开启后台限制)

@EmmaSwan

就这个（获得已经连接的 wifi 的信息）问题来说：

"thanks.看来真是天残，谷歌一日不改，安卓就不存在隐私"
iOS 有同样的问题

@greenskinmonster

AppOps 从 Android 4.3 开始就存在了
6.0 出现的变化是：
1：增加了 adb 的接口
2：对应与 6.0 的运行时权限所需的新增的一些 OP(如 OP_READ_PHONE_STATE)