prateek135 / mylockforandroid Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/mylockforandroid
Automatically exported from code.google.com/p/mylockforandroid
What steps will reproduce the problem?
1. Answer an incoming call
2. End the call
3. Observe as lockscreen shows up
What is the expected output? What do you see instead?
Users expect myLock always skips lockscreen. Instead the phone app is being
permitted to restore it only in this case where it remembers that the call
arrived while the lockscreen was in effect.
This will be able to be fixed in the next minor release. A temporary
workaround is that you can double press power and myLock should properly
skip the lockscreen on receiving the screen on event.
Original issue reported on code.google.com by [email protected]
on 8 Jan 2010 at 3:53
What steps will reproduce the problem?
1. All steps are taken to enable pattern lock with timeout.
2. Droid was rebooted.
3.
What is the expected output? What do you see instead?
Expected was to seen pattern screen to unlock via preset pattern.
What happened was Droid was unlocked by simply using the slide to unlock
screen
What version of the product are you using? On what operating system?
Latest version on android
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 14 Apr 2010 at 5:13
Though security is still detected for pattern lockscreen, we no longer have
access to disabling it via our change_settings permission. Soon a Froyo
release will be ready which removes all reference to security interaction.
The previous version for the eclair build will go back up soon as well to
allow for smoothest operation pre-Froyo, as it has not been released on the
droid (our primary target device) officially yet.
Original issue reported on code.google.com by [email protected]
on 6 Jun 2010 at 7:26
What steps will reproduce the problem?
1. Play music
2. Pause it
3. Try to accept call via phone tools prompt
Music starts again instead of accepting call.
This happened under the rockon player. It may be a bug with that app's
handling. I'll be testing further.
Original issue reported on code.google.com by [email protected]
on 2 May 2010 at 2:37
What steps will reproduce the problem?
1. Press power or any keypad button swiftly
2.
3.
What is the expected output? What do you see instead?
It seems the OS has an issue and ignores our wakeup at times. It most often
duplicates immediately after a deliberate power key sleep. Other times we
simply get no response to a press (however under the hood the wakeup and
unlock has been executed by the OS has sent itself to sleep before anything
was visible). Other times you see it come on then go dark again. You can
always avoid the issue by pressing and holding the key for a slightly
longer amount of time, then releasing. It appears to be a power manager bug
that we sidestep in the timing. It will never occur if stay awake mode is
left on.
Please use labels and text to provide additional information.
Original issue reported on code.google.com by [email protected]
on 30 Jan 2010 at 6:26
What steps will reproduce the problem?
1. Dialing a phone number
2.
3.
What is the expected output? What do you see instead?
the default lock activates in a few seconds maybe 2 seconds.
What version of the product are you using? On what operating system?
android 2.2
Please provide any additional information below.
would like the lock not to appear when I initiate a call.
Original issue reported on code.google.com by [email protected]
on 26 Jun 2011 at 7:57
What steps will reproduce the problem?
1. Put screen to sleep while running hide lockscreen mode
2. Sleeping over the top of an app such as google talk or the browser has
more consistently duplicated the issue
3. Wake screen with power key
What is the expected output? What do you see instead?
The bug we had a few versions back where the system Keyguard screen was
regaining control during the wakeup and causing the display to go back to
sleep (though the unlock still finishes, meaning you can wake it back up
with any key at that point) is back thanks to the froyo change that broke
our translucent dismiss window that we had relied on to clear the keyguard
without any jagged on-screen transitions.
I can fix this but I'll need to spend some time testing the mode and
further tweaking it. Time which I don't have right now, so please
reinstall 1.4b from the downloads page if you are still on eclair and
impacted by this bug. I'm considering rolling back the change and
uploading a separate froyo-only package, but that's a lot of work too.
The android team has expressed that they simply do not care about this bug
and will not provide options to easily return control to the lockscreen or
cleanly close the lockscreen when the user requests to exit for use with
the dismiss keyguard / show while locked attributes.
Original issue reported on code.google.com by [email protected]
on 2 Jun 2010 at 11:05
What steps will reproduce the problem?
1. rebooting the app
2.
3.
What is the expected output? What do you see instead?
It is expected that the app will require your unlock pattern once after
reboot and then turn off your unlock pattern until timeout limit is
reached. What is happening is after reboot, the lock pattern is disabled,
the app is disabled, and the timeout is disabled leaving an unsecured
phone.
What version of the product are you using? On what operating system?
1.5 Android (Droid)
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 11 Apr 2010 at 11:24
Please comply with the GPL by making the source code of this application
available to the public. The easiest way will probably be uploading it to
existing Google Code project page. Thanks!
Original issue reported on code.google.com by [email protected]
on 30 Jan 2011 at 9:28
What steps will reproduce the problem?
1. Start MyLock in background mode
2. Call your cell
3. Answer the call
What is the expected output? What do you see instead?
Normally no error would appear as the call was answered. Instead, as the
call is answered a box appears stating
Sorry!
The application myLock (process i4nc4mp.myLock) has stopped unexpectedly.
Please try again.
Force Close
What version of the product are you using? On what operating system?
I am using http://mylockforandroid.googlecode.com/files/myLock_alpha2b.apk
downloaded 1/5/2009. My OS is the Greek 2.1.041 on a rooted droid.
Please provide any additional information below.
The crash seems to occur whether the phone is locked or not. Also it will
continue unlocking automatically until it crashes twice, then the auto-
unlock feature no longer works.
Original issue reported on code.google.com by [email protected]
on 5 Jan 2010 at 11:07
What steps will reproduce the problem?
1. Uninstalled and reinstalled mylock.
2. Set pattern lock and enabled status icon.
3. Rebooted Droid.
What is the expected output? What do you see instead?
Expected to display pattern unlock screen at boot.
What actually happened was Droid can be unlocked by simply sliding on
unlock screen after reboot(no pattern unlock screen).
What version of the product are you using? On what operating system?
1.3.4a Droid Version 2.1
Please provide any additional information below.
I followed instructions on issue 27 without any luck.
Original issue reported on code.google.com by [email protected]
on 15 Apr 2010 at 4:28
What steps will reproduce the problem?
1. Place pandora widget into the Widget Setup screen while pandora is
playing. This causes the proper playback updated widget to be created
2. Exit the widget setup or view the lockscreen itself
What is the expected output? What do you see instead?
The pandora widget goes back to blank state, the state pandora gives it
for when the widget is added before the account is logged in or before any
playback station is started. I believe the cause of this issue is twofold
1- Pandora is allowing a local service to spawn in the individual widget
instance, which connects to the playback service at time of create.
2- The homescreen isn't typically closed down and recreated very often, if
ever in the stock Launcher. The lockscreen is typically closed down when
exited, and recreated at sleep.
The end result is that a local service being spawned inside the widget
view, to bind back to the playback service to determine what is/was
playing (this is per the widget tutorial from google in which they spawn a
local service to retrieve a word of the day update in the example widget).
This is not a good idea for a music playback widget which will have
frequent changes. It is not noticed by most users since the stock Launcher
isn't closed down very much, however it causes the widget to break in our
lockscreen environment.
Pandora could fix this issue by implementing a more appropriate remote
service to call update out to the widget. This remote service would not be
destroyed when the lockscreen is exited, whereas the currently implemented
local service IS destroyed when that widget's view is destroyed at
lockscreen close. The service doesn't get recreated until the time
interval widget update happens. This must be in place to resolve the blank
widget after a device reboot. I am going to notify pandora of this
solution suggestion.
Please use labels and text to provide additional information.
Original issue reported on code.google.com by [email protected]
on 5 Apr 2010 at 9:14
What steps will reproduce the problem?
1. With MyLock (I think) the 3G is left on by default, when I leave home
2.
3.
What is the expected output? What do you see instead?
By the way, I really like MyLock, it is just that I would like to see it
automatically reconnect with Wifi I have used before at a location.
Instead I have to manually pick it from Settings, Wireless and Network.
What version of the product are you using? On what operating system?
Just downloaded it this week. I use Android 2.1.
Please provide any additional information below.
Great product so far. I think you have done fine work with this app.
Original issue reported on code.google.com by [email protected]
on 9 Apr 2010 at 10:38
What steps will reproduce the problem?
1. Set an alarm or receive a handcent notification
2. Try to wake during the alarm/event
What is the expected output? What do you see instead?
It seems to very strongly resist proper wakeup code. I am not sure yet the
cause under the hood. When my alarm goes off I have to open the slide to
get the screen to wake so I can shut it off. It has not been consistent in
response time. It might be that a long lag is occurring, as at times the
wakeup lag seems to get significant and most so with these certain waiting
notifications. The cause is a window flag that's meant to preserve
notifications. Without the flag, the alarm quits immediately because of the
existence of the custom lockscreen.
Please use labels and text to provide additional information.
Original issue reported on code.google.com by [email protected]
on 30 Jan 2010 at 6:28
What steps will reproduce the problem?
1. start mylockforandroid
2. select "Use widget welcom..."
3. press "Toggle lockscreen skip"
4. welcom screen will show now
5. press "back" key
What is the expected output? What do you see instead?
since this is "lock" app, press back key won't show anything
What version of the product are you using? On what operating system?
on emulator, target 2.0.1, api level 6.
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 11 Jan 2010 at 1:51
What steps will reproduce the problem?
1. Make a call then end it, or receive a call and have other party end it
while screen is asleep
2. Wake up the screen
3. This next wakeup results in the default lockscreen instead of the custom
lockscreen
What is the expected output? What do you see instead?
The suspected cause of this error is a problem with not receiving the
screen off broadcast because screen off is happening during the call when
we have paused the broadcast receivers. For the placed call, it seems the
fact that device is unlocked is not being properly detected so the failure
to place the custom lockscreen occurs because the screen off logic believes
that the custom lockscreen already exists.
Alpha 3 pre-release test build exhibits this issue with implementation of
the key-customizable customLockscreen.
Original issue reported on code.google.com by [email protected]
on 17 Jan 2010 at 5:55
What steps will reproduce the problem?
1. Place a widget via Widget Setup
2. Enable myLock
3. Lock device then wake it up, then lock it, then wake it up again
What is the expected output? What do you see instead?
Visuals on the widgets are no longer updating.
I've identified the fix and I am going to be able to make a fast fix
tonight and upload it to market.
Original issue reported on code.google.com by [email protected]
on 1 Apr 2010 at 10:57
What steps will reproduce the problem?
1. ?
2.
3.
What is the expected output? What do you see instead?
I am trying to enable the regular lock screen, or the more secure lock
screen. But NO LockScreen comes up at all. And now all of my side buttons
UNLOCK my phone...I would just like my normal settings before I installed
MyLock. I have uninstalling and reinstalling mylock and changing the
setting. But nothing works! What can I do to get my lockscreens back?
What version of the product are you using? On what operating system?
MyLock Auto Unlock version 18. on Droid 1.1-update1
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 20 Apr 2010 at 3:28
What steps will reproduce the problem?
1. Enable myLock from the regular settings screen or bootup auto-start
2. Place Lite mode widget button on home
3. Press the button then try to lock and unlock the phone
What is the expected output? What do you see instead?
Expect lockscreen to be disabled but because of the conflict between the
lite and regular mode mediators the lockscreen rules are broken and no more
lockscreen disables will work.
The current test build alpha 3 has this issue. If lite is active then
regular mode is enabled it seems to have no conflict because it auto-stops
the lite mode correctly. This is planned to be fixed by doing a workaround
to have the preferences file gain a setting when lite or regular modes are
active.
Original issue reported on code.google.com by [email protected]
on 17 Jan 2010 at 5:58
What steps will reproduce the problem?
1. Using myLock complete 2c, toggle off persistent settings notification
icon (foreground mode)
2. Use the device for a while
Users have reported that rarely, myLock appears to be getting destroyed by
the OS, resulting in random unexpected appearance of the lockscreen.
I believe this is due to memory management that occurs automatically. It
may also be influenced by any task killer apps (which are largely
unnecessary on android). The settings launcher in notifications also keeps
the service running in foreground mode, protecting it from being shut off
in low memory scenarios -it uses an extremely minimal CPU resource as it
is.
Original issue reported on code.google.com by [email protected]
on 11 Jan 2010 at 7:47
What steps will reproduce the problem?
1. Just does it on and off all day randomly...
2.
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system? Did it on
android 2.2 and 2.3
Please provide any additional information below.
I have over half of my system memory still available and it pops up about 10
times a day.
Original issue reported on code.google.com by [email protected]
on 14 Jun 2011 at 1:13
What steps will reproduce the problem?
1. activate myLock standard 2.0 version (Any mode)
2. sleep the screen
3. wake up with power key
What is the expected output? What do you see instead?
lockscreen dismiss fails. this is because in 2.2 all forms of translucent
or transparent lockscreen overriding windows are prevented by the system
keyguard mediator, it seems. prior to 2.2, only the show_when_locked flag
windows would get blocked when using the translucent layout.
You can actually use the cupcake beta on 2.2 because it uses a black
opaque window and the older keyguard manager API, but sometimes still
fails due to the cpu processing speed.
This occurred for me in the emulator for 2.2 SDK running the 2.1 built
package. I have yet to test building the package on 2.2 to see if there is
actually any difference possibly in the backwards compatibility setup.
We may have to completely scrap the clean dismiss keyguard method we've
been relying on and go back to the basic pre 2.0 keyguard override API; if
so I'll be very disappointed despite all the great improvements of 2.2
I have had a bug report open on the android project page about this
behavior on the show_when_locked window. I'll update the issue report with
link to that so we can try to get an explanation
Original issue reported on code.google.com by [email protected]
on 21 May 2010 at 5:41
What steps will reproduce the problem?
1. Try to lock the phone while browser, dolphin browser, or facebook are on
screen
2. Try to unlock
What is the expected output? What do you see instead?
The lock override is not creating correctly at sleep. Instead the OS is
putting it off, such that it happens at screen on. So in custom lock mode,
you see the lockscreen for a moment then the normal first-start screen
force off happens, making you think it failed to wakeup. In the regular
mode, you end up just seeing the dummy unLockScreen, that you normally
don't see since it is created while screen is off. To proceed you have to
sleep then wake again. This is the last remaining significant quirk on the
alpha 3 test builds.
Original issue reported on code.google.com by [email protected]
on 27 Jan 2010 at 8:51
What steps will reproduce the problem?
1. Install App
2. Configure App (Not sure on all the settings - need help here)
3. Use App
What is the expected output? What do you see instead?
I would hope that I can use the app to unlock the phone via the camera
button and volume rocker keys. I have been looking for app forever that
would do this. I am not fond of the power button.
I believe the issue is isolated to myself figuring out a proper
configuration for the app. Can someone (I would REALLY appreciate it)
explain what settings/protocols I need to be using to bypass the power
button and use the camera and rocker buttons to unlock the phone?
What version of the product are you using? On what operating system?
Droid 2.01 (Rooted). Latest version I believe.
Please provide any additional information below.
I would thank anyone that provide help!
Original issue reported on code.google.com by [email protected]
on 7 Feb 2010 at 7:13
What steps will reproduce the problem?
1. No problem - enhancement request
2.
3.
What is the expected output? What do you see instead?
Camera button press when screen is sleeping does nothing
What version of the product are you using? On what operating system?
Droid v2.0.1
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 15 Mar 2010 at 6:58
Known scenarios:
* Speakerphone/Bluetooth is active, screen was allowed to go to sleep and
remain asleep for 5 or more seconds, causing system to initialize the
lockscreen again.
* Any call ends by the other party while screen is asleep (not always,
still trying to determine if it has anything to do with whether a lockscreen
was in place when the call came in)
Original issue reported on code.google.com by [email protected]
on 16 Feb 2010 at 5:22
Security on the new prefs will show correct reading but will not change it
in the file so that boot startup is handled correctly. it also breaks when
going to non secure from secure (fails to disable pattern that is active)
Original issue reported on code.google.com by [email protected]
on 6 May 2010 at 8:42
What steps will reproduce the problem?
1. Execute the "Widget Setup" app
2. Press Start Over
What is the expected output? What do you see instead?
The screen should be blank, without any widgets. Instead, the huge clock is
always there and I am unable to remove it.
What version of the product are you using? On what operating system?
myLock_v1.4b_release.apk
myLock_widgetLockscreen_r2a.apk
Original issue reported on code.google.com by vitalyb
on 2 Jun 2010 at 11:28
it has been confirmed that this is because of a lockdown to system security
level of the itelephony methods. same as the changing of security status that
happened in 2.1. we will need to develop a rooted super-user enabled version of
the app to restore these features for 2.3 and on
Original issue reported on code.google.com by [email protected]
on 10 Feb 2011 at 8:25
What steps will reproduce the problem?
1. Unlock the device via power key
2. Try to long press home or short press search
3. Observe as nothing happens
What is the expected output? What do you see instead?
Expect search or app-switcher dialogs. What happens is that the long-press is
never handled though the haptic occurs. When we release the home key, the
screen flickers. Now that we have done this, the buttons will work. It seems
to continue working for a short while even if re-slept and awakened.
Original issue reported on code.google.com by [email protected]
on 29 Dec 2009 at 11:20
LWhat steps will reproduce the problem?
1. Lock phone with button
2. Unlock phone
3.
What is the expected output? What do you see instead?
Phone should be ready for use but instead it locks again
What version of the product are you using? On what operating system?
Latest lite version
Please provide any additional information below.
I first noticed the problem when auto lock happened with the onscreen keyboard
up.
Original issue reported on code.google.com by [email protected]
on 12 Jan 2010 at 6:34
What steps will reproduce the problem?
1. Enable myLock custom lockscreen, disable 'secure mode'.
2. Enable alarm.
3. When alarm sounds, exit myLock screen.
What is the expected output? What do you see instead?
The alarm is still sounding and there is no way to stop it short of
powering down the phone.
What version of the product are you using? On what operating system?
myLock widget Lockscreen 1.1 beta r2 on an HTC Desire phone.
Original issue reported on code.google.com by joost.cassee
on 19 May 2010 at 7:14
It appears all milestone users have reported this error. I'm still
researching on a possible fix from our end.
Original issue reported on code.google.com by [email protected]
on 21 Jan 2010 at 8:46
What steps will reproduce the problem?
1. Enable 2.1 3D launcher home. Live wallpaper doesn't impact
2. Sleep the device at the homescreen
3. Open the slider to wake it up (without slide guard enabled)
What is the expected output? What do you see instead?
The dismiss message "waiting for cpu to restore last app" is visible. No
buttons work but notification bar does and able to sleep via power key.
The log shows what's happening is the activity is never given focus. The
focus gain is what we rely on to know the keyguard has been completely
dismissed.
It appears to be a bug in this custom Launcher rendering system. Because it
does not have focus, it occasionally gains it after we press power to
sleep, waking device back up and completing the unlock. I tested it with
translucent or wallpaper display, and also with animation vs no animation.
Original issue reported on code.google.com by [email protected]
on 30 Mar 2010 at 3:05
What steps will reproduce the problem?
1. Set idle timeout
2. Enable myLock
3. Allow timeout to occur, then wake the phone
What is the expected output? What do you see instead?
Users expect to see the pattern unlock immediately to know that the
timeout was successful and to have the fastest unlock experience possible.
Instead the regular slide unlock must be done, then we see the security
screen.
I will implement a fix for this via a quick update to the main myLock
package. We can actually cancel the lockscreen that we are seeing there by
requesting a secure unlock (same method as first 1.0 myLock) on the first
screen wakeup after the timeout occurs.
Original issue reported on code.google.com by [email protected]
on 12 Apr 2010 at 12:36
What steps will reproduce the problem?
1. Set an HTC alarm and allow the device to sleep
2. Allow the alarm to wake up the device
3.
What is the expected output?
Alarm has two notification methods: slider on keyguard enabled screen or
notification box on "awake" screen. With keyguard dismissed I would expect
to see the notification box
What do you see instead?
There is no notification visible. This actually makes it completely
impossible to dismiss or snooze the alarm!
What version of the product are you using? 1.4b On what operating system?
HTC Desire running Elcair 2.1 and HTC Sense. I am not sure if the alarm is
an Android alarm or an HTC alarm
Please provide any additional information below.
The app called AutoLock manages to ensure that the "awake" notification is
displayed leaving the alarm functional, so I guess this must be possible.
Original issue reported on code.google.com by golightlygl
on 23 May 2010 at 8:46
Uninstall and reinstall is required to resolve this. Some pref files failed
to convert to the new shared userID path required by the new version. This
causes prefs to only last during the session. Restart will wipe them.
Original issue reported on code.google.com by [email protected]
on 13 Apr 2010 at 3:02
xoom and tablet in general really need a separate app marked for 3.0 and coded
without any phone permissions, this way we can also optimize for speed and any
customization we might want to unlock for 3.0. I'm pretty sure we're still as
boxed in as ever for what we can do with customizing unlock but I am looking
into this.
Original issue reported on code.google.com by [email protected]
on 25 Feb 2011 at 6:22
What steps will reproduce the problem?
1.
2.
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 16 Apr 2010 at 1:03
What steps will reproduce the problem?
1. Start some music
2. Press power to go to sleep
3. Try to change volume via the side key
What is the expected output? What do you see instead?
User expects to be able to change volume. It's possible this won't work due
to custom lockscreen logic.
It's possible there is no fix to this given current limitations of custom
lockscreen implementation. However, the workaround suggested would be to
use the Lite mode that does not utilize any lockscreen and merely exits the
lockscreen automatically at wakeup. The beta version will feature the more
implemented custom lockscreen with option to disable it in favor of the
lite no-lockscreen method currently featured in alpha 2c. the advantage of
custom lockscreen mode is more control over what actions will wake or
unlock the device.
Original issue reported on code.google.com by [email protected]
on 28 Jan 2010 at 7:50
What steps will reproduce the problem?
1. Initiate a phone call
2. While in call, allow screen to timeout and sleep
3. Wake up the screen
What is the expected output? What do you see instead?
Expected output is to wakeup without the lockscreen. Instead the lockscreen
happens every time, even if the proximity sleep or manual button sleep are
done. Issue does not happen if you do proximity sleep before a timeout
sleep occurs.
The planned solution is to implement code which aborts the handling of
screen on/off broadcasts when the call in progress notification exists. We
are researching easiest way to code this case.
Original issue reported on code.google.com by [email protected]
on 29 Dec 2009 at 11:24
Several users have experienced a stop of the service for no apparent reason,
and have to re-enable it from widget or prefs. It has been able to be prevented
by running in notification mode, this keeps the service protected from any
system initiated memory-freeing shutdown. I am still investigating the official
root cause, and have yet to be certain if it would impact all 2.3 users.
Original issue reported on code.google.com by [email protected]
on 17 Feb 2011 at 5:59
What steps will reproduce the problem?
1. press power button
2. look at screen
What is the expected output? What do you see instead?
in previous versions to alpha 2c, a press of the power button would
smoothly load the screen into the unlocked front page. Now whne pressing
the power button, there is about a 1 second hesitation where sometimes i
will see the slide to unlock screen, it freezes for a second and then
unlocks. Sometimes it completely fails to unlock, and i turn the screen off
and then back on and it works. It doesnt smoothly unlock anymore, taking
1-2 seconds now instead of close to no time at all in previous versions.
What version of the product are you using? On what operating system?
mylock alpha 2c
im useing a rooted 2.01 rom with the sholes overlay for 2.1 apps
Original issue reported on code.google.com by [email protected]
on 7 Jan 2010 at 7:31
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 [email protected]
on 6 Apr 2010 at 7:03
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.