Android有关性能监控的问题（及Linux的proc机制）

参考《Linux Filesystem Hierarchy》一书中的proc章节，我们能更清楚的了解linux的proc机制，并且弄清楚里面每一个子文件/子文件夹的内容。我们已有的项目主要就是通过获取/proc/文件夹的内部信息来进行操作的，所以嘛……还是要好好理解一下这个滴~

保密问题具体函数怎么写的就不发在这啦，但是因为涉及到了linux的proc机制所以我们看一下这几篇文章：

Jared Rummler的博客《Android Processes & Security》中有这么一段话：

In Android 7.0 (Nougat) Google significantly restricted access to the file system which makes it impossible to get a list of running processes using my library. The lead developer of CopperheadOS was kind enough to outline the changes reducing access to /proc:

The procfs filesystem is now mounted with hidepid=2, eliminating access to the /proc/PID directories of other users. This change was implemented in CopperheadOS and was then adopted upstream based on it. There’s a group for making exceptions but it’s not exposed as a permission. It’s only used to make exceptions for some processes in the base system. It could be exposed as a ‘dangerous’ permission and it’s what I expected Google would end up doing but they decided that users wouldn’t understand the implications of it.
＞
https://android-review.googlesource.com/#/c/181345/

SELinux policies also became much stricter. For apps, there’s no baseline access to /proc at all anymore, although that only applies to files other than the /proc/PID directories. There’s still access to a few files with labels not falling under the general proc policy, but it’s mostly gone. This has been gradual and there are many relevant commits. One of the big ones:

https://android-review.googlesource.com/#/c/105337/

This not only removes a lot of obvious information, but it also closes some more blatant security holes involving side channels allowing things like logging keyboard input:

https://www.lightbluetouchpaper.org/2016/07/29/yet-another-android-side-channel/
https://staff.ie.cuhk.edu.hk/~khzhang/my-papers/2016-oakland-interrupt.pdf
SELinux policies have also become a lot stricter in general over time. You can see the rest of that in the platform/system/sepolicy repository. Note that it was at platform/external/sepolicy for a long time but it was recently moved.

See: https://stackoverflow.com/a/38728738/1048340

嘛大概也很好懂，就是没有其他应用的proc/<进程号>的访问权限了嘛。。。
我还不信邪，又看了一下简书博客——《app前台判断那点事
》里面的方法6，也说了这个问题。

甚至包括绿盟科技博客——《【移动安全】App客户端劫持及简单防护》里也再强调权限锁紧的问题。

结论：所以目前为止感觉比较好的解决方案是把这个独立的app的代码中部分移植到内嵌到待检测的app中，后续怎么用还是看安排吧~

---

公司这边还是要求，看看能不能通过别的方式——（除了遍历/proc文件夹以外的方式）获取到Android其他的进程，虽然我个人持悲观态度，看了上面几篇文章，尤其是Jared Rummler的博客《Android Processes & Security》，我感觉希望渺茫……尤其是你看看Google公司内部的android开发的commit记录（链接和截图如下），都说现在根本就没有办法获取到其他进程了。https://android-review.googlesource.com/c/platform/system/core/+/181345

（PS:上面这些事Google公司自己开发的时候员工写的日志，应该说很权威了。。。。）

好，反正有任务还是要尽最大努力进行尝试，还是想了一些方法进行调研。

我先是这么试的：在adb shell $环境下，首先得到我们的Monitor程序的pid = 20300, 另外开的一个应用的 pid = 20027，现在pid 是 通过 adb shell 获取到的应该没什么问题了。

• 为了进行测试我先是写死，new一个AndroidProcess出来，提供Pid = 20027，结果抛出了异常java.io.FileNotFoundException: /proc/20027/stat (No such file or directory)。所以甚至写死，把这个进程add进去也没有用。

• 在上面这步结束出错之后，我没有着急进行报告，我先猜测了有下面这几种可能：

  1. 如我所想，Android 系统更新之后，每一个应用已经完全无法访问到其他进程的内容（这个可能性我目前感觉是最大的，而且，虽然我现在还不100%确定，不过linux系统获取到进程信息的方法好像就只有访问/proc文件夹这一种，如果真的是这样，大概就不可能实现了。）
  2. 第一步的时候有一个推测， linux系统获取到进程信息的方法好像就只有访问/proc文件夹这一种，那么这个推测会不会是错的呢？如果还有别的访问linux，或者说android的进程信息，是不是就能够访问了呢？
  3. 会不会是现在的AndroidProcess这个类的构造函数有问题，用pid来new的时候没有正确使用呢？

• 上面这三种可能逻辑上已经完全覆盖了。从最简单的开始，我们先调研第3个可能——是不是new错了呢？查看源码发现，果然都是使用的访问/proc/pid/cmdline的方式获取的，从现有逻辑看应该没问题。

• so，那就需要调研第2个可能了——是不是通过/proc/pid访问文件的形式获取进程本身就不对呢？或者说是不是有其他的获取方法呢？我百度，google了一圈，还是没有找到合适的，有些博客给的方法都是旧有的，根本没法正常使用。现在无论是直接通过/proc文件获取，还是通过actvityManager.getRunningAppProcesses()方法获取，得到的都是一个size = 1的List。(PS:搜索获取进程相关信息，获取linux进程信息，获取android进程信息，get process information， android get process information等关键词都试了，baidu google stackoverflow都没有相关的方法。像https://www.cnblogs.com/lovelyYakir/p/5886961.html这些博客讲的方法甚至还是项目里目前在使用的com.jaredrummler.android.processes包呢…就更不好用了。。。)

可能我的调研还不够深入，但是目前来看应该是不可能哇……先写这些，后续我的调研还在持续ing。