Android 5.0/6.0进程自动重启调研（5.0+）
众所周知，在Android 5.0+，系统安全有了比较大的提升。守护进程也不像4.4之前那么容易了。比如通过fork等创建的子进程也会同父进程一样被Kill.
那么到底在5.0+上发生了什么变化呢？带着好奇，决定走进去看一看究竟....
初探
查看ActivityManagerService.java源码，发现在M上kill进程时多出了一句Process.killProcessGroup(app.info.uid, pid);
也就是这一句，保证了在杀死APP的同时，也结束掉它fork/exec创建出来的所有子进程。
final void appDiedLocked(ProcessRecord app, int pid, IApplicationThread thread) {
..............
Process.killProcessQuiet(pid);
Process.killProcessGroup(app.info.uid, pid);
app.killed = true;
那么事实真的是这样吗？
Demo1: fork一个子进程
示列代码如下：
pid_t pid = fork();
if(pid < 0){
return;
}else if(pid > 0){
return;
}else{
}ps打印出的进程：
USER PID PPID VSIZE RSS WCHAN PC NAME
u0_a64 16992 317 1536924 52588 ffffffff 00000000 S com.example.testndk2
u0_a64 17011 16992 1504092 34508 ffffffff 00000000 S com.example.testndk2可以看到有两个进程，17011便是在JNI中通过fork创建出的子进程。
在5.0+上只要kill 16992,17011也会被kill.而在4.4上，则不会。
Demo2: fork出的子进程再fork子进程
这么做的目的是为了测试子进程被init进程所领养后的情况是否也如此。
示列代码如下：
pid_t pid = fork();
if(pid < 0){
return;
}else if(pid > 0){
return;
}else{
}
pid = fork();
if(pid < 0){
return;
}else if(pid > 0){
return;
}else{
}ps打印出的进程：
USER PID PPID VSIZE RSS WCHAN PC NAME
u0_a64 18602 317 1538796 53848 ffffffff 00000000 S com.example.testndk2
u0_a64 18650 1 1504092 34508 ffffffff 00000000 S com.example.testndk2
第二个进程的父进程变为了1，也就是init进程。
测试发现若kill 18602,18650也会一同被kill。
这究竟是怎么回事呢？
原来这是因为在5.0+上开启了Control Group来管理进程.
它会把进程以及它的所有子进程都绑到了一个组里面管理，这样就能做到将所有子进程都杀了。
关于cgroup的参考资料：
http://lxr.free-electrons.com/source/Documentation/cgroups/cgroups.txt
http://www.linux-kongress.org/2010/slides/seyfried-cgroups-linux-kongress-2010-presentation.pdf
具体到android中，相关的代码文件：
system/core/libprocessgroup/processgroup.cpp对代码进行分析：
在AMS中杀App时，会调用到processgroup.cpp的killProcessGroup函数，看下该函数会做什么：
int killProcessGroup(uid_t uid, int initialPid, int signal)
{
..........
while ((processes = killProcessGroupOnce(uid, initialPid, signal)) > 0) {
if (retry > 0) {
usleep(sleep_us);
--retry;
} else {
break;
}
}
..........
}可以看到在killProcessGroup中只是循环调用 killProcessGroupOnce，再看看该函数又是做什么的：
static int killProcessGroupOnce(uid_t uid, int initialPid, int signal)
{
while ((pid = getOneAppProcess(uid, initialPid, &ctx) >= 0) {
processes++;
......
int ret = kill(pid, signal);
if (ret == -1) {
SLOGW("failed to kill pid %d: %s", pid, strerror(errno));
}
}它通过getOneAppProcess循环获取子进程id,再kill掉。
进入getOneAppProcess查看，最终发现子进程是从下面这个函数组成的文件名中读取到的：
static int convertUidPidToPath(char *path, size_t size, uid_t uid, int pid)
{
return snprintf(path, size, "%s/%s%d/%s%d",
PROCESSGROUP_CGROUP_PATH,
PROCESSGROUP_UID_PREFIX,
uid,
PROCESSGROUP_PID_PREFIX,
pid);
}#define PROCESSGROUP_CGROUP_PATH "/acct"
#define PROCESSGROUP_UID_PREFIX "uid_"
#define PROCESSGROUP_PID_PREFIX "pid_"
#define PROCESSGROUP_CGROUP_PROCS_FILE "/cgroup.procs"所以上面的函数组成的文件名是这样的：
/acct/uid_%d/pid_%d/cgroup.procs再通过adb进入手机看看这个目录：
root@cancro:/acct/uid_10064 # cd pid_18602/
root@cancro:/acct/uid_10064/pid_18602 # ls
cgroup.clone_children
cgroup.event_control
cgroup.procs
cpuacct.stat
cpuacct.usage
cpuacct.usage_percpu
notify_on_release
tasks
root@cancro:/acct/uid_10064/pid_18602 # cat cgroup.procs
18602
18650看到jni中fork创建出的子进程18650也确实被记录在了该文件中,这是cgroup在fork,exec等的回调中完成的。
此时也就解释了为什么kill APP时，所有fork出的子进程也会被kill.
总结：
这样要在5.0上做自己的卸载提示等，看样子就不可能了。
fork出的进程生命周期与App生命周期是绑定在一起的。
重启的解决方案：
通过研究几款App，能够在被kill后还能重启的方案可能就只有利用service或者广播了。
查看工商银行的客户端，重启的机制是在Service的onDestory()函数中重新启动自己，demo code如下：
虽然这种方式不是特别的靠谱，但在5.0+上，可能这就是目前能够做的了吧。
public class MyService1 extends Service {
private MyReceiver1 a;
private MyReceiver2 b;
public IBinder onBind(Intent paramIntent)
{
return null;
}
public void onDestroy()
{
startService(new Intent(this, MyService1.class));
super.onDestroy();
}
}