[Defy Android Development] YetAnotherForumUser:
Test: how to test kernel audio subsystem without interference from Android

Given the way all file system access stalls when the 'ringtone' bug hits this is a kernel problem. A problem in the 'AUDIO LIB' would affect audio but leave other basic system services alone. That is clearly not the case.

An interesting experiment for a creative hacker comes to mind. Take a phone which has started showing the signs of the 'ringtone' bug. Get a remote shell on it through adb (connected to USB, not through WLAN). Run the basic tests to make sure it really is hit by the 'ringtone' bug and not something else. Once you're sure it is, run the following command (root needed)

# stop

This will terminate zygote (the parent process for all Dalvik VM instances) which terminates most of Android on the phone. What you are left with is a somewhat limited Linux machine which is fully accessible through adb.

Here is some example output to see what I'm getting at:

# uptime
up time: 1 days, 09:58:45, idle time: 08:35:49, sleep time: 17:20:12
# ps|grep zygote
root 1282 1 163260 16016 ffffffff 00000000 S zygote
#
# stop
# ps|grep zygote
# uptime
up time: 1 days, 10:10:22, idle time: 08:44:30, sleep time: 17:20:11

Now open a second terminal on your PC and use it to get a shell on the phone. Use that shell to monitor a file in the /proc filesystem, eg:

$ watch -n 1 cat /proc/interrupts

Open a third terminal and use it to display the output from logcat:

$ logcat

Open a fourth terminal and use it to display the kernel message queue (root needed):

$ su
# cat /proc/kmsg

Open a fifth terminal and use it to display some process statistics using busybox's top applet:

$ busybox top

Watch the numbers changing. Once you are satisfied with the amount of instrumentation, go back to the first shell (the one you used to enter the stop command) and enter the following command:

# stagefright -a -o /system/media/audio/ringtones/*

You should hear a series of ringtones playing. If everything works as it should this should not have any effect on the output in the other terminals, the numbers should keep on changing. Does everything work OK? No error messages in logcat (third terminal) or the kernel message queue ('dmesg', fourth terminal)? Nothing hogging the CPU or memory in the fifth terminal?

Once done - or once fed up with the endless stream of ringtones - use CTRL-C in the first (stagefright) terminal to terminate that process. Finally restart zygote, and with that the rest of Android:

# start

Your phone will display the boot animation and dump you in the lock screen (if you have one) or on the home screen. Android is alive again. The uptime has not been affected by this exercise:

$ uptime
up time: 1 days, 10:42:35, idle time: 09:04:01, sleep time: 17:20:11

Sometimes wifi will not come up immediately, in that case stop/start wifi the normal way until it does.

As I'm still testing JellyX and I 'unfortunately' have not had any 'ringtone' bug since I started these tests I can not try these experiments on a phone currently exhibiting those symptoms. All I can say is that on my phone the above resulted in a maddening stream of inane ringtone sounds which did not affect the output in the monitoring terminals at all - everything kept on flowing nicely, the system load average was around 1, logcat only gave those [FONT="Monospace, Courier New"]D/AudioHardwareMot( 1284): Output bufSize from kernel = 8192[/FONT]' messages, /proc/kmsg did not show anything out of the ordinary, it all just worked. If it does not work on a phone exhibiting the bug (either no sound, or stuttering sound, or no updates in the watching terminals) the problem clearly lies somewhere between the kernel and stagefright - all native code. If it does work it becomes more complicated. Try to put more load on the phone, does that make the bug appear? Try to reduce the amount of available memory, be creative.

By the way, I did try to restart zygote back when the ringtone bug started appearing (several weeks ago) to see whether that would be sufficient to get rid of it. It wasn't.

By the other way, it is of course also possible to try these commands while zygote (and with that, Android) is running. Be creative, test, torture and find out what kills it.

---------- Post added at 02:04 AM ---------- Previous post was at 01:41 AM ----------

I'd guess that would have a noticeable impact on battery longevity as it requires the capacitive digitizer to be enabled all the time. If this feature is to be enabled in a build I'd prefer it to be optional.