Progress update for next alpha & beta

I am now one bug fix away from launching these The bug is that certain apps are stopping the correct operation of the 2.0 optimized method I am now using. When screen first sleeps, my process attempts to get started and ready to give you a lag-free, unlocked wakeup. Basically primes itself by taking over the lockscreen. But if browser was open, this fails, & instead it only starts when you wake the screen up. It's like the request gets paused and the OS puts it off till we wake the screen up again. The result is you have to sleep it again and wake up again to get unlocked, because the logic is to do nothing at start, and wait for the next wakeup. When google talk or the home screen launcher (or even the home replacement I use- slidescreen) no conflict happens, it works like it should. But then when you're trying to wake it up to resume where you were in browsing, it just doesn't get started correctly. Totally misses the boat. The point of the 2.0 method is that it is very smooth and fast, and never fails due to CPU load. It never has a flicker. You never see the stock lockscreen since we override it at sleep. So this next release will be really solid and a better experience, if there is any fix for this bug.

You can download a totally functional test build that shows where we are at with this, it just will have a large issue trying to work on the first try when browsing or a few other apps. For the actual alpha 3 it will have no widget lockscreen option as that method won't be finished till we have launcher functions & key customization working within it (for the beta). Other than that it should include a preference whether sliding open should cause the unlock, to help protect against accidental pocket slider bumps, have had some requests for that.

Update: Still trying to resolve some more bugs. Going crazy over the failure to wakeup that seems to happen with a lot of attempts following the power key re-sleep. My current fix seems to resolve it when timeout sleeps happen. the bug doesn't want to happen when i'm plugged in to USB monitoring the program log. something in the timing is the only root cause I can think of.

I have a fix so it very reliably yields to any screen popup and runs very smoothly, plus allows exit via home key and use of notification bar. If i can get this bug killed then I will add the option if users want an Unlock slider and roll out alpha 3 with some cool new options and the custom lockscreen....

Android issue 6298: Unexpected KeyEvent results during sleep with activities using show when locked or dismiss keyguard flags

Submitted to the official issue log. This problem is responsible for the difficulties we are currently trying to work around to get things into beta-quality consistency.

- Steps to reproduce the problem:  I start up an activity upon receipt of screen off broadcast. The activity  adds the FLAG_SHOW_WHEN_LOCKED before inflating layout. I then call  TakeKeyEvents(true). This is supposed to allow the activity the chance to  handle key events even if it doesn't have focus. My activity does have  focus at time of creation, while the screen is off, but can lose it by  other things I do with the app. I ultimately want it to always handle key  events even if it has been pushed to the background.  - What Happened: I don't get key events. It seems I can only get events that are "wake keys"  as defined by the KeyguardViewMediator: {{{ private boolean isWakeKeyWhenKeyguardShowing(int keyCode) {         switch (keyCode) {             case KeyEvent.KEYCODE_VOLUME_UP:             case KeyEvent.KEYCODE_VOLUME_DOWN:             case KeyEvent.KEYCODE_MUTE:             case KeyEvent.KEYCODE_HEADSETHOOK:              case KeyEvent.KEYCODE_MEDIA_PLAY_PAUSE:              case KeyEvent.KEYCODE_MEDIA_STOP:              case KeyEvent.KEYCODE_MEDIA_NEXT:              case KeyEvent.KEYCODE_MEDIA_PREVIOUS:              case KeyEvent.KEYCODE_MEDIA_REWIND:              case KeyEvent.KEYCODE_MEDIA_FAST_FORWARD:             case KeyEvent.KEYCODE_CAMERA:                 return false;         }         return true;     } }}}  - What you think the correct behavior should be. The window isn't able to take precedence over any key guard. Though the  display gets precedence, one does not expect that key events will still be  bound by the lockscreen. It effectively prevents your activity from  responding at all to the keys above. A related detail is the fact that the  opposite seems to happen when you use the FLAG_DISMISS_KEYGUARD. At that  point any key will cause wakeup if sleep happens while your activity is  still in progress. This behavior also seemed unexpected, as when sleep  occurs we are generally expecting the keyguard to be re-instated, but the  flag seems to be preventing that while the activity is alive.  I believe this problem affecting both flags should be considered a bug. A  fix would be appreciated, allowing these flags to be used in conjunction  with key event handling without unexpected lockscreen override of the  events. An example of what I expect to happen with either of these flags  would be if I return true on an event, that means I wanted to handle it, if  I return false then the event could next pass to the KeyguardViewMediator  to see if a wakeup should happen, etc. As it stands the event won't get  passed on in cases of sleeping while activity is alive, causing either the  unexpected unguarded wakeup, or failure to process keys that would normally  not be wakeup keys.   This happened within 2.0.1 SDK, this flag was added in API 5 and could be  extremely useful to app developers whilst there is no specific intent  support for replacing the lockscreen.

MILESTONE PARSE ERROR RESOLVED--updated

Thanks for throwing me a bone, Bernhard Fuhry. Glad it worked. Revising very frequently now trying to complete an official alpha 3 with all the major feature improvements I've been working on and bug resolutions. Sorry the custom lock preview mode in that build is a little buggy. If interested try the more recent build revisions as I post them.

Custom button unlock and wakeup proof of concept achieved

Thanks to a window feature called flag_dismiss_keyguard new in 2.0 I can put my own lockscreen in place every time the screen sleeps (cancelling the regular lockscreen). Then I can respond to keys however I want using regular key event handling. While I can't stop the cpu from waking up because android doesn't give apps permission to define wakeup rules, my lockscreen doesn't turn your screen on unless its a key event that we actually want to wake it up. It sends the cpu back to sleep in 5 seconds. Since it isn't doing anything it doesn't impact battery at all.

This pre-alpha test build lets camera key wake it up (once awake you see a clock, and you can use the notification panel, or press back to unlock) and keeps volume and focus camera key presses from waking the screen. Power still instant unlocks just like the rest of the myLock versions.

I am skipping alpha release for this as the first implementation of it is already in myLock complete (though non-functional as a lockscreen) and my test build APK is also up for download because I forgot to delete it.

The beta is pending completion of To-Dos:

• Add phone listener that stops it from placing the custom lockscreen during calls -- done
• Handle opening the slider as a wakeup event (stays asleep currently) -- done
• Support customization for users to add widgets & app launchers -- proof of concept for widgets is done
• Get the home key exit consistently processing correctly --mostly done
• Get the phone call event handling rock solid --- mostly done
• Figure out how to let the power key still unlock after an accidental press of a locked key --got a working fix that inexplicably won't work for the volume keys but does for camera/cam focus
• figure out why random apps seem to interfere when lockscreen comes on over the top of them -- no idea. it seems to be odd lag and because it takes too long the lockscreen can't close itself since screen isn't waking up
• Implement the 5 second re-lock grace period and also a longer timeout for pattern lockdown
• Implement settings screen for configuring unlock/wakeup/locked down keys. I will ensure it supports double press and long press as well. Maybe you want all keys locked down except when double pressed. It will be able to do that.
• Possible implementation of a lockdown mode. This is an extra security level allowing the user to place phone into lockdown requiring they type in their password to get out of it. The lockdown mode works by intercepting attempts to leave the lockdown screen and forcing it to open again. If I can get it rock solid where it even overrides the call answering screen, then I may include this feature in the beta.
• Finish creating the 2.0 optimized lock-skip mode that actually uses a replacement lockscreen window with no customization -- 70% done

Making progress- release first incarnation of myLock lite

myLock lite is an implementation of the lightest-weight lockscreen disable (short of the one that allows all buttons to wake up device - which does do by stopping lockscreen from ever being active) we've tested. This first release gives you a 1x1 widget that is used to turn myLock lite on or off. When it comes on or off a notification appears, which is a one time rather than a persistent mode like in myLock complete. It will also update the notification when a phone call happens as myLock functionality interferes with the phone app's control of the lockscreen while it turns screen on or off via the prox sensor.

The thing to know with this version is that it works like alpha 1. When you first wake up the device, the lockscreen is being paused. This means that the home long press and search keys are still locked out and using them will cause the pattern unlock to appear if you have one- if you do not, then pressing home once should cause a screen flicker at which point the home long press & search should be enabled.

I've also added pattern mode smart auto-toggle. what this does for you is pauses pattern security mode when you toggle myLock lite on. It will lock the device back down into pattern mode when you toggle it back off.

I've added the download link to myLock lite over on the left sidebar. This is the version I want to get out onto the market sometime soon.

version 2c - minor update

All I did was isolate and stop the cause of the force close upon receiving call. It has a slight optimization in how the stay awake is handled, and has a check box for the welcome homescreen to replace lockscreen. That doesn't work very well at the moment and is not functional at all for adding widgets so I don't recommend turning it on. If the screen is put to sleep with it up any key will wake screen back at that point.


At the moment I don't expect another update will be needed until we have some of our widgets done and the ability to place them on the welcome lockscreen.

This should give us time to turn up any other minor case bugs.

Update - version alpha 2b

This version provides settings toggle for the foreground mode, and a new tool - stay awake mode which you can check and the screen will not auto-sleep.

The lockscreen skip itself must be toggled by the main button because the settings has no way of reading whether the service is running. first press will get status, turn it on if it was not, and then 2nd press confirms stop. When foreground mode is off, you won't know it's on until you try to wake the phone. But go ahead and use it if you don't like the persistent icon. I am not sure if there are bugs once you change settings but the functions being toggled have all been tested up to now in independent past versions as the features were built, so I am betting it is all pretty stable. I was able to toggle everything from various states of operation and have it all come out as expected. But alpha as always means try not to get too mad if something breaks or fails! ;]

Please send feedback to mylockandroid at gmail. Thanks!

Also check out the new faq before contacting us. Double thanks.

(Download link is posted on the sidebar at left)