Here we present the various tests we've made to support the freezing of applications and processes.
Here we present two tests that automatically freeze the application and every process to it associated.
In order to do this we employ a mechanism similar to the one used for the Task Kill.
This scenario is composed of an application which creates a process in which there is some native code running. That native code then forks itself and creates another process which is a grandchild of the app's process.
Result: Both the app and processes get frozen correctly as was expected.
This scenario is composed of an application which creates two processes that make the ping shell command.
Result: Both the app and processes get frozen correctly, but afterwards the emulator becomes unresponsive and the kernel becomes panicky.
Here we present two tests in which we sent terminal commands to the app's process and associated processes individually.
This scenario is similar to the Scenario 2 of Automatic Task Kill.
Result: The app gets frozen correctly, but afterwards the emulator becomes unresponsive and the kernel becomes panicky.
This scenario is similar to the Scenario 2 of Automatic Task Kill.
Result: The processes get frozen correctly and evething is fine, but when we freeze the app the emulator becomes unresponsive and the kernel becomes panicky.
There is only one difference between the two process configurations presented.
In the first configuration, the child processes of the app, basically spin, without doing any work.
In the second configuration, both processes issue a shell command, which forces the app process to transition into a TASK_INTERRUPTABLE state, meaning the process runs in the kernel mode.
What we've observed with these tests is that freezing an application which has processes running in kernel mode, usually brings undesired results.
On the other hand, another interesting finding when performing these tests was that despite verifying that these processes running in kernel mode, transition from the TASK_INTERRUPTABLE (S) to the TASK_STOPPED (T) state, when we issue the strace -p <kernel_mode_process_pid> command, we can see that those processes despite being in the T state, are continuously performing socket system calls (sendmsg, recvmsg), which seems to mean the signal doesn't actually stop kernel level code.