ARGH ... reconstructing a long and perfectly-worded post from amnesiac-memory because the Android default browser reloads web-pages when you switch applications ... my Ally time-out powered-off 10+ paragraphs into a long post and reloaded this page (clearing the posting-box) when I woke it up (I may have to disable Executive-Assistant, the on-wake-up info page if this becomes a nuisance, but I wish I could disable auto-reloads in the browser).
I apologize if this second attempt to answer you skips over anything ...
=-=-=-=-=-=-=
Watchdog-reboot-timers are a good OS design on expected-use appliances like DVRs and phones, especially where the system-programmers know what chunks of code will have access and rights to "lock" key system resources and consider any N-second delay to be a malfunction or extremely unusual condition.
Watchdogs are dangerous when users have the capability to install non-manufacturer software onto their system / PC, especially when that software directly interacts with system interrupts and resources and the user may not mind pauses (and our installations of Windows do have so very many pauses).
But by definition, smartphones are expected-use-appliances that users can install software to to do important things like dealing with time-critical message streams.
Watchdog reboots in our case are similar to:
1: user-land programs are not supposed to rigidly lock key system resources
1a: and probably should not set maximum-priority+watchdog status
2: but Drive-Safe.ly or K-9 etc are being triggered by an incoming message alert
3: they launch but for some reason are prevented from engaging their pop-up box or other mandatory action because something else was holding a key system resource locked and failed to renew / refresh the lock in time for this watchdog timeout (renewal would have put the program back at the tail of the queue for resource X, which 99% of the time would be empty and nothing would change, but it allows the Android/Linux kernel to process the queue in case something else wants to get a word in edgewise.)
4: because a high-priority incoming message was not allowed to progress through the user-defined procedure-tree, (note the conflict of paradigms there), the watchdog reboots the Android-device under the (incorrect/complicated) assumption that the system was resource locked (which is actually true from a certain point of view).
=-=-=
It is possible that my reboots were from an email-triggered source also, since I only noted message-arrived,music-continued,reboot,Drive-Safe.ly-speaks ...
DS speaks both email and text messages, but when I get email on my commute, it is invariably from my co-workers, and I have a strange email-system in place that sends me a SMS message anytime a co-worker emails my work address, and if I am more than an hour idle on my unix system, ALSO forwards that email to my phone-monitored-gmail-account.
I am certain that _some_ messages did not cause crashes (I get frequent SMS messages via AOL-AIM from my server+network-monitoring-systems), but uncertain which ones did not cause crashes between the human-origin SMS+gmail and robot-origin SMS-only. I have a nagging (amnesiac) memory that just after the 3-days-ago crash, DS spoke from gmail but not the SMS that accompanied it.
I'll trigger this intentionally for my next commute and observe how things happen.
In your case, I would suggest that you
1: set up a Linux at-job or Windows scheduler job to email you something during a known time window of your commute
2: just before that commute, turn ON everything you normally would, except
3: turn OFF the K-9 message-arrival pop-up window notification.
From the Fedora-11 manpage for the at command ...
For example, to run a job at 4pm three days from now, you would do at 4pm + 3 days, to run a job at 10:00am on July 31, you would do at 10am Jul 31 and to run a job at 1am tomorrow, you would do at 1am tomorrow.
The program will then put up a "at> " prompt and wait for you to enter commands until you give it an end-of-file trigger (control-d ... generally on a line by itself)
... so if your commute is 0800 to 0830, you would do the following
MyLinuxSystemPrompt$
at 8:15 Jul 6
at> echo this is a test | mail -s "Ally reboot test" MyEmailAddr@gmail.com
at> ^d
job 1 at 2010-07-06 08:15
Although you should test this in non-commute hours also just to confirm that your Linux system can in fact send / deliver email to somewhere that can deliver it to your gmail account _in_a_timely_manner_. My home and work Linux / FreeBSD systems all deliver email to my gmail account in under a minute, but you should always test this (mail queues can be set to flush instantly or every 15 / 30 / 60 minutes or arbitrary time values ... alternatively, you may have firewalls in the way stopping you from direct-delivery to external email servers)
In Windows, to open Scheduled Tasks, click
Start, click
All Programs, point to
Accessories, point to
System Tools, and then click
Scheduled Tasks.
Since the scheduled-tasks wizard wants to have you run a program, you'll have to have something set up ... I suspect that sending email from a batch-file is asking far too much from a paradigm that predates the web or GUIs, but MicroSoft has a wonderful system called "PowerShell" which will run on XP or later (I am uncertain about Win2000 or earlier, but you'd assumedly have very good knowledgable reasons to be on anything that old now). I believe that there are thousands of available powershell script examples around that will show you how to send email just by launching a powershell script ... so launching it from the scheduled-tasks-wizard will do so just as well and you can schedule your test.
As an aside, do you have anything else (like Executive-Assistant) installed that may try to "help" with email notifications ... their help may be counter-productive.