Lags of alarms in Motorola Milestone or all its devices??

Some people owned Motorola devices complained to me about the lags of their scheduled alarms or even not went off. I googled and found many people have the same problem on their devices especially Milestone, even the built-in AlarmClock. I am not very sure who should be blamed. I tried to find out why in an "economic" way (I don't want to buy another Motorola phone). I downloaded their SDK add-ons to emulate Motorola devices on their website.

According to users report, their failed alarms are scheduled to go off when device sleeps. So, I did the following steps to replicate their condition.

• Turned AC power off in emulator
• Setup an alarm that will go off after power off

Indeed, this alarm didn't go off at scheduled time. But, it went off when you turn device on.

I carefully inspect the logs line by line and found these lines interesting.

03-29 12:38:21.536    62    96 V ActivityManager: Broadcast: Intent { act=android.intent.action.TIME_TICK flg=0x40000004 (has extras) } ordered=true
03-29 12:38:21.536    62    96 V ActivityManager: Enqueueing ordered broadcast BroadcastRecord{43ae6820 android.intent.action.TIME_TICK}: prev had 0
03-29 12:38:21.536    62    96 I ActivityManager: Enqueueing broadcast android.intent.action.TIME_TICK
03-29 12:38:21.551    62    74 V ActivityManager: Received BROADCAST_INTENT_MSG
03-29 12:38:21.551    62    74 V ActivityManager: processNextBroadcast: 0 broadcasts, 1 serialized broadcasts
03-29 12:38:21.564    62    74 V ActivityManager: Processing ordered broadcast BroadcastRecord{43ae6820 android.intent.action.TIME_TICK}
03-29 12:38:21.564    62    74 V ActivityManager: Submitting BROADCAST_TIMEOUT_MSG for 869828
03-29 12:38:21.564    62    74 V ActivityManager: Delivering serialized to registered BroadcastFilter{439d1460 ReceiverList{439d85e0 62 system/1000 local:43a24fb8}}: BroadcastRecord{43ae6820 android.intent.action.TIME_TICK}
03-29 12:38:21.564    62    74 I ActivityManager: Delivering to ProcessRecord{43b67508 62:system/1000}: BroadcastRecord{43ae6820 android.intent.action.TIME_TICK}
03-29 12:38:21.564    62    74 I ActivityThread: Receiving broadcast android.intent.action.TIME_TICK to android.app.ActivityThread$PackageInfo$ReceiverDispatcher@43a27b00
03-29 12:38:21.564    62    74 I ActivityThread: Enqueueing broadcast android.intent.action.TIME_TICK to com.android.server.AlarmManagerService$ClockReceiver@43a28528
03-29 12:38:21.564    62    73 I ActivityThread: Dispathing broadcast android.intent.action.TIME_TICK to com.android.server.AlarmManagerService$ClockReceiver@43a28528
03-29 12:38:21.571    62    73 V ActivityManager: Finish receiver: android.app.ActivityThread$PackageInfo$ReceiverDispatcher$InnerReceiver@43a24fb8
03-29 12:38:21.571    62    73 V ActivityManager: processNextBroadcast: 0 broadcasts, 1 serialized broadcasts
03-29 12:38:21.571    62   100 D WindowManager: interceptKeyTq event=android.view.RawInputEvent@43acae08 keycode=26 screenIsOn=false keyguardShowing=false
03-29 12:38:21.571    62   100 D PhoneWindowManager: inECBM: false
03-29 12:38:21.571    62   100 D WindowManager: interceptKeyTq event=android.view.RawInputEvent@43acae08 keycode=26 screenIsOn=false keyguardShowing=false

Why interesting? The TIME_TICK events. It is plausible that I suspect Motorola optimizes their devices by stopping clock as system goes to sleep and restarting it as system goes back on. This sounds plausible.

I really need to think about how to fix this if Motorola doesn't want to fix this and OpenAlarm keeps not-functioning in user feedback. Damn it.