weimingtom / mylockforandroid Goto Github PK

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.

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!

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.

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.

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.

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.

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.

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!

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. 

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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

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) 

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.

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.

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.

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. 

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.

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.

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.

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)

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.

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. 

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.

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.

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.

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.

It appears all milestone users have reported this error. I'm still 
researching on a possible fix from our end. 

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.

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.

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.

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

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.

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.