android/ios 生态环境从来都是自上而下，厂商如果不想就只能效仿 yunOS 分裂 android

从 chromeos 的安全与隐私保护力度来看，谷歌并不是不注重保护用户，而是没有找到大刀阔斧改革的时机。一方面是吸引开发者，另一方面是 android 碎片化太严重。现在 android 地位无可撼动，加上 project treble 出来后，用户对厂商的依赖大幅减少了，也是时候注重安全了。

如果紧张到杀带 service 的进程通常是内核绕开 android 层直接杀，整个进程都会死。

@paparika 做音乐播放当然要前台 service+常驻通知，前半段思路就是官方推荐做法。我不是做 UI,后半部分我不好评价，但感觉显示播放状态应该是 service 驱动 activity，而不该让 activity 主动去 pull。是不是用 rxjava 之类的反转控制技术好些？

还有 Activity 是否执行 onDestroy 与 Application 是否重建没有因果关系。只要进程不被杀，哪怕是 cached-process,你的所有 static/singleton 的值都还在，甚至里面还能有一大堆线程继续运行任务都可以。

我一直觉得 android 里面的 service 是挂羊头卖狗肉，尤其是那些没有提供 onBind 的 service，除了向系统表达一下”我很重要别杀我”之外什么软用都没有。一个 app 可能有 10 个后台 service，但很可能只有一个线程负责处理这些 service。这样 10 个后台服务与两个效果一模一样（需要两个服务才能耍流氓,A 拉起 B，B 拉起 A ）。

两种情况都可能出现.第一种情况系统内存不太紧张，系统会先执行 onDestroy,进程状态变为 cached process。然后系统再从所有"cached-process"里面选择杀。

当系统把所有的 cached-process 全杀光了，内存还是不够(比如 512M 的手机经常这样)，系统就直接杀非空进程，根本不管你的 onDestroy 是否执行了

BAT 巨头们玩热更新还要更恶心，需要消耗更多流量和存储空间。 只要 app 更新时没要新权限，我觉得都可以接受。你用 web 版或者小程序，每一次使用也会自动加载最新版本，效果一样的。

@EmmaSwan 比如酷安就有增量更新，可以省不少流量。

@yuriko @imcczy 你们是说拿到别人的 Application Context，还是说在 PackageManager 里面的 ApplicationInfo ？ SystemUID，你是说你写的是随系统安装的 priv-app 吗？

稍微警醒点的 app 应该不会随便把 context 拱手送人，因为这就菊花外漏任人宰割了。当然很多第三方 sdk 可能会强行索取 context 不给就罢工，然后 sdk 可能偷偷把 context 走私出去？可是 android 系统级服务又不是傻子不会用调用第三方 sdk.

@yuriko 你要是能做到跨应用反射，去谷歌那领几百万美元奖金绝对没问题。

@datou 基本每一个有 LOS14.1 official 的机型，在 xda 上都会有同一个开发者放出的 unofficial LOS15.1

@honeycomb 我咋记得 AOT/JIT 混合编译是从 N 开始的。M->N 的 apk 安装速度提高一截，N->O 没感觉有变化。

可安装的 apk 在这里:https://github.com/android-hacker/VAExposed/releases

@skylancer 试了试改高德地图，配合这个补丁 https://github.com/Lanchon/haystack，有效运行。

@yuriko 反射只能对自身进程有效，哪怕是对同一个 app 下的另一个进程都无效，更何况是对不同 UID 下的进程。

@imcczy 应用安全 apk 加壳我不熟，但系统安全，包括 linux 内核 /selinux/binder/permission 机制我都很熟，aosp 各种系统服务源代码也没少看。


还有最近有了免 root 的 xposed 的方案:https://github.com/haygcao/VAExposed，这个是一个薄容器，里面甚至自带签名伪造功能，无需 xposed: https://github.com/haygcao/VAExposed/blob/master/VirtualApp/lib/src/main/java/com/lody/virtual/server/pm/parser/PackageParserEx.java#L53
当然，这个东西既然与 apk 本身运行与同一个进程中，那么就容易利用反射来针对。

@MarkTonyFromMars 我用 keepassdroid 保存密码的。支持自动填写密码是不是要换密码管理器呢？

感觉 Lineage 15.1 没有 14.1 好用。15.1 限制后台有 bug，效果还不如开了 appops 的 14.1。也不知道是 lineageos 没及时同步到最新代码还是 8.1 照样有 bug。

之前觉得 oreo 最大看点是 auto fill framework,可是目前没看到我用的 app 有支持。

@huclengyue @honeycomb 获取签名的函数是通过 IBinder 在 ActivityMangerService 的系统进程中实现的，java 反射怎么可能穿越进程甚至穿越不同 UID 呢？

@zjb861107 开源即可

@skylancer 之前改过 whatsapp 和另外一款依赖 gcm 的开源软件，可以运行。国内流氓还没试过。待会儿试试高德地图

@didikee java 代码是孙悟空，manifest 是如来神掌。java 代码怎么写也不能脱离 manifest 控制，动态广播没有权限是没用的，哪怕有权限，app 不在后台运行时也是没用的。

@honeycomb 所以我在原帖了说了“尽量做到每个 apk 单独签名"，这样不同的 app 就没法利用相同签名获取别人家的权限。

@meisky6666 修改 2 确实可能出现这个问题，但还有 1 和 3 可以改，风险相对小。

还可以利用社区的力量，做些类似于绿守处方的东西，让小白也知道对于某些特定 apk，哪些服务 /权限能禁哪些不能禁。比如*.permission.MIPUSH_RECEIVE 这种权限，我打赌你全禁掉也没事。