Android root 相关调研
需求
老大给的需求 1，sdk/apk 拦截手机短信，并且清除手机系统短信收件箱该条短信记录。2，安装 apk，最好是静默安装
需求分析
短信拦截
首先手机短信的拦截应该是很好实现的，目前竞品中有很多已经实现了该功能的产品，如 360 手机卫士等。因为短信广播是系统级别的广播，只需在 Manifest.xml 里加"接收"SMS 的权限，再注册一个 receiver 便可以监听到短信的收发，至于拦截部分，可以通过 ContentObserver 进行拦截监听。在 4.4 前，短信拦截都是通过动态注册高优先级 BroadcastReceiver 的方式进行拦截的，主要是用于跟竞品进行短信抢占。而现在 ContenetObserver 是并行通知的情况下，如果过滤逻辑不够快，依然有可能会被竞品抢先把短信先删除掉，导致拿到的最后一次短信是旧的短信。建议结合 BroadcastReceiver 和 ContenetObserver 进行拦截，BroadcastReceiver 做内容校正和后备数据，以防拿到的最后一条短信是旧的时候，依然可以进行正常的拦截流程。
相关资料代码有
apk 安装
要是说静默安装，那只能 root 了，这个难度比较大，所以做了些系统的调研工作。首先现在主流的 root 竞品应用 1，kingroot2，pingpongroot3，360 超级 root4，一键 root 大师 5，百度一键 root6，超级 root 大师 7，root 精灵 8，root 助手
何谓 root
Android 系统默认的 su 程序只能 root 和 shell 可以用运行 su。不光 root 手机上 su 需要设置 SUID，所有的 Linux 系统上的 su 程序都需要设置 SUID 位。这样我们就可以看出其实 Android 系统的破解的根本原理就是替换掉系统中的 su 程序，因为系统中的默认 su 程序需要验证实际用户权限（只有 root 和 shell 用户才有权运行系统默认的 su 程序，其他用户运行都会返回错误）。而破解后的 su 将不检查实际用户权限，这样普通的用户也将可以运行 su 程序， 也可以通过 su 程序将自己的权限提升，然后利用 superuser.apk 将已提权的系统进行管理。所以 root 得本质都是将 su 文件复制到 Android 系统/system/xbin 目录下，将所有者更换成 root 用户，并用 chmod 命令设置为可执行权限和 setuid(s)权限。
所以现在的 root 软件都是做了上面的工作，首先得解决提权的问题，所以千千万万的挖洞工作就开始了。已经利用的漏洞整理.
又 google 到相关机型的特定 root 提权漏洞
等等等
挖洞难，利用这些洞绕过系统内核的安全机制更不容易，并且 android 内核碎片化严重，通用的洞几乎找不到，所以亦是比较佩服这些专做 root 的团队精英。Google Code 上找到了 zerbrush 老版本的源码，经测试 4.1 以前的 android 版本都可以 root（测试的不够充分）。
总之，root 设备难度比较大，因为 android 的碎片化太严重了，想找通用洞肯定是不可能的，大部分 root 应用都应该有自己维护的一套机型 root 漏洞库，通过获取设备型号匹配相应的 root 方案，进行 root，所以 root 核心方案肯定不只一套，并且 5.0 以上的系统几乎很少有 root 应用进行提权，因为内核漏洞补丁也在持续更新修复，以上版本的 root 会更加困难。
插件化
相对于 root，插件化方案看上去更加可行。
插件化解决的问题
1，减小主包大小 2，不发版上新功能 3，独立开发加载 A/B TEST 模块 4，bug 修复工具首先插件化和热修复能不使用就不使用，本身这种做法是 Google 不推荐的，RN 才是今后的发展方向。apk 分为宿主和插件部分，插件在需要的时候才加载进来。
实现插件化需要解决的技术点
1，资源如何加载（资源冲突问题如何解决）？2，代码如何加载访问访问？3，插件的管理后台包括的内容？4，插件的增量更新问题（非必须）5，加载插件中的 so 库 （非必须）
相关开源
详细
目前插件包有两种格式：一种是 apk,一种是 dex 包．对插件的接入机制来说也有两种：一种是需要安装，一种是不需要安装．结合插件包的格式来说插件的方式只有三种：１，apk 安装，２，apk 不安装，３，dex 包．三种方式其实主要是解决两个方面的问题：１，加载插件中的类，２，加载插件中的资源．第一个加载类的问题，这三个方式都可以很好的解决．但目前三种方式都没有很完美的解决第２个问题．
１，apk 安装方式．插件 apk 安装后，可以在主程序中通过包名加载到插件的 context,有了插件的 context 就可以解决加载插件资源的问题．但出现的新问题是：如果插件 a,b,c 间公用一个底层 jar 包，那么在 abc 间传送数据时，需要进行序列化和反序列化，因为 a 中 jar 包的 data 类与 b 中 jar 包的 data 类虽然都是同样的 jar 包也是同样的类，但两个类在 java 机制来是由不同的 classloader 加载的，是不同的类．那么就会出现插件间 jar 包冗余和数据传递的效率不好问题．总之能解决问题．
２，apk 不安装，这个是不推荐的方式．可以通过 dexclassloader 加载到插件 a 中的类，但插件没有安装就无法获得插件 apk 的 context，也就无法加载到资源，网络上有牛人通过将主程序的 context 替换关键的对象（如 classloader,assertmanager 等），伪造成插件的 context，然后通过伪 context 也可以获得插件资源．目前个人验证的问题为：获取到的 layout 资源中的 textview 显示文本有问题，无法显示在 layout 设定的文本．同时个人猜测这种 hack 的方式或许有其它的未知的问题，但不排除高手已经解决了这个问题．
３，dex 包，这个基本是 java 开发中 jar 包的方式．同样通过 dexclassloader 加载到插件中的类，但依旧没有 context,也无法加载到资源．要使用布局，只能在插件中使用 java 代码来写布局．这种方式最简单（１，类似 jar 包的方式，也可以随意导出单个类的 jar 包然后转化为 dex 包，不存在打包成 apk 需要完整的工程和依赖关系的要求．２，底层的公用 jar 包所有插件可以公共一个，传递数据不用反复的序列化和反序列化．），也是最复杂的（布局文件全部代码写，难调试，难维护）．
优缺点
插件式开发通俗的讲就是把一个很大的 app 分成 n 多个比较小的 app，其中有一个 app 是主 app。基本上可以理解为让一个 apk 不安装也可以被运行。只不过这个运行是有很多限制的运行，所以才叫插件否则就叫病毒了。其实在目前淘宝、百度、腾讯、等都有成熟的动态加载框架，包括 apkplug，但是它们都是不开源的。
优点：1.模块解耦 2.解除单个 dex 函数不能超过 65535 的限制 3.动态升级 4.高效开发(编译速度更快)
基于插件的开发列举两个比较突出的优点：1、应用程序非常容易扩展，比如一个新的领域要加到旧的应用程序中，只需把这个新的领域做为一个插件，只开发这个小的 app 就可以了，旧的应用程序可能会原分不动，就连编译打包都不需要。2、下载更新特别省流量，假如一个应用程序有 10M 把它分成两个的话可能每次更新只需要花费 5M 或者更少的流量就可以更新完。
追求完美本来就是一种性格缺陷，说在做软件方面没有近乎完美。基于插件开发当然不是插件越多越好能掌控好内聚和耦合度就更好了。插件增加了主应用程序中的逻辑难度。有优点的东西也是有缺点的这是必然。
缺点：1.增加了主应用程序的逻辑难度 2.技术有难度，目前一些成熟的框架都是闭源的
参考资料
1.android 插件化及动态部署 - ATLAS--伯奎（阿里无线事业部无线技术专家）
2.怎么将 Android 程序做成插件化的形式？
3.Android 插件化 动态升级
4.apkplug 框架
5.Android 插件化开发，初入殿堂
6.Android 插件框架 AtlasForAndroid（阿里使用框架）
Simple Project
总结
插件化，热更新也是近期才火的黑科技，确实可以解决一些实质性的问题，比如也可以适当的实现前面说的免安装 apk，但是也会有一定的局限性。总之，功能需要继续调研.360 的插件化开源框架。
我就是个零 2018.06.14 加入
程序员而已
评论