Handcent process occasionally prevents myLock from receiving screen off or user present unlock broadcasts

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Have handcent running
2. Lock the phone (widget lockscreen) or unlock it (wallpaper enabled auto 
unlock version)

What is the expected output? What do you see instead?
Handcent is launching something in response to screen off occasionally, and 
I've also observed it launching a "nextsms" item when I am expecting user 
present to be coming in to the wallpaper auto dismiss process..

04-06 12:57:47.062: VERBOSE/screenon(18891): Screen just went ON!
04-06 12:57:47.218: VERBOSE/guard is handling wakeup(18891): deciding 
whether to dismiss
04-06 12:57:47.218: INFO/ActivityManager(1105): Starting activity: Intent { 
flg=0x40050000 cmp=i4nc4mp.myLock/.DismissActivity }
04-06 12:57:47.265: VERBOSE/handoff to dismiss window(18891): pausing, 
expecting user present soon
==========Here is the handcent event that breaks the user present broadcast
04-06 12:57:47.289: INFO/ActivityManager(1105): Start proc 
com.handcent.nextsms for broadcast 
com.handcent.nextsms/com.handcent.sms.transaction.SmsReceiver: pid=18963 
uid=10059 gids={3003, 1015}

04-06 12:57:47.296: VERBOSE/dismiss(18891): creating dismiss window
04-06 12:57:47.375: VERBOSE/dismiss gained focus(18891): sending window to 
back
04-06 12:57:47.382: INFO/ActivityManager(1105): moveTaskToBack: 481

======Here is where we see that the lockscreen comes back.
That would not happen if the dismiss had worked. It appears the handcent 
item is actually stopping the lockscreen dismissal from working
04-06 12:57:47.500: DEBUG/ddm-heap(18963): Got feature list request
04-06 12:57:47.554: DEBUG/KeyguardViewMediator(1105): pokeWakelock(5000)
04-06 12:57:47.625: INFO/ActivityManager(1105): Process 
com.android.settings (pid 18937) has died.
04-06 12:57:47.679: DEBUG/SurfaceFlinger(1105): Screen about to return, 
flinger = 0x116728
04-06 12:57:47.937: INFO/ActivityManager(1105): Displayed activity 
i4nc4mp.myLock/.DismissActivity: 652 ms (total 652 ms)
04-06 12:57:47.968: VERBOSE/destroy_dismiss(18891): Destroying
04-06 12:57:52.789: INFO/power(1105): *** set_screen_state 0
====And the screen goes back off in this scenario because of lockscreen 
restore
I don't know what has happened to the guard activity in this case, because 
if we wake and unlock, user present goes ahead and the lifecycle finishes.
I don't know of a way we can work around this. I'm going to report it to 
handcent and warn my users that there could be problems. I am seeing this a 
lot during testing though I'd expect it to be relatively uncommon for an 
average user.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by myLockan...@gmail.com on 6 Apr 2010 at 7:03

[GoogleCodeExporter]

Here the issue also occurs, visible that some service is being killed off at 
the 
moment we want to be getting user present. Perhaps this is a bug in android

04-06 13:44:59.590: VERBOSE/screenon(19499): Screen just went ON!
04-06 13:44:59.754: VERBOSE/guard is handling wakeup(19499): deciding whether 
to 
dismiss
04-06 13:44:59.754: INFO/ActivityManager(1105): Starting activity: Intent { 
flg=0x40050000 cmp=i4nc4mp.myLock/.DismissActivity }
04-06 13:44:59.778: VERBOSE/handoff to dismiss window(19499): pausing, 
expecting user 
present soon
04-06 13:44:59.809: VERBOSE/dismiss(19499): creating dismiss window
04-06 13:44:59.895: VERBOSE/dismiss gained focus(19499): sending window to back
04-06 13:44:59.903: INFO/ActivityManager(1105): moveTaskToBack: 521
04-06 13:45:00.051: INFO/ActivityManager(1105): Process com.motorola.calendar 
(pid 
19650) has died.
04-06 13:45:00.239: DEBUG/SurfaceFlinger(1105): Screen about to return, flinger 
= 
0x116728
04-06 13:45:00.293: DEBUG/KeyguardViewMediator(1105): pokeWakelock(5000)
04-06 13:45:00.364: INFO/ActivityManager(1105): Displayed activity 
i4nc4mp.myLock/.DismissActivity: 563 ms (total 563 ms)
04-06 13:45:00.403: DEBUG/skia(1105): purging 194K from font cache [18 entries]
04-06 13:45:00.489: VERBOSE/destroy_dismiss(19499): Destroying
04-06 13:45:05.528: INFO/power(1105): *** set_screen_state 0
04-06 13:45:05.547: DEBUG/SurfaceFlinger(1105): About to give-up screen, 
flinger = 
0x116728
04-06 13:45:05.684: VERBOSE/screenoff(19499): Screen just went OFF

Original comment by myLockan...@gmail.com on 6 Apr 2010 at 7:45

[GoogleCodeExporter]

The fix might be having dismiss activity wait for user present. test build is up

Original comment by myLockan...@gmail.com on 6 Apr 2010 at 8:17

[GoogleCodeExporter]

waiting for user present in the dismiss window itself resolved this 
vulnerability. at 
times, processes requiring system resources would delay the actual lockscreen 
dismissal. we found at times we would get user present before focus gain in the 
dismiss 
window, but other times after. it was those times where we were getting focus 
and not 
yet dismissal that this error sometimes happened. we now wait for system to 
confirm 
that lockscreen is cleared before pushing the dismiss window into the 
background. it is 
airtight

Original comment by myLockan...@gmail.com on 7 Apr 2010 at 12:27

• Changed state: Fixed