Utility lockscreen first build progress

Just need to fix this to add the leading zero to the first 10 hours & minutes. This cap was taken while testing the secure mode first alpha code and it works perfectly as it is really very very uncomplicated compared to the lockscreen cancelling variant.

---Got it all fixed.. And yes visual enhancement isn't my forte, these are just plain Button elements that I've slapped the function labels on for now. And also added battery % to top left corner.

Alpha 2c launched in market as myLock beta v1

I decided launching in market would be a good idea to reach more people & get more feedback, now that we've given the build a whole month to make sure it's solid enough and realize the most important improvements.

Please take a minute to leave positive reviews if you have been following us.

======

So far we've discovered a few new bugs.

The lockscreen appears to restore, possibly causing a conflict, when speaker or blutetooth is active and then you let the screen sleep during a call. when you then end the call lockscreen is restored, it appears to be an android bug

The cpu clock mods seem to cause a problem when set too low for sleep, also. This doesn't appear to impact the a3 revisions.

More about the first release to contain our utility lockscreen

Today I made some decisions to revisit the simpler idea of the replacement lockscreen. While I still want to implement open widget usage for greater end user flexibility, this is the vision I want to achieve for the first beta release containing the custom lockscreen:

• myLock utility lockscreen - featuring the utility widget with clock display, controls for vibrate/sound, brightness level, and also music player interface (album art will be able to display), and optional unlock slider interfaces, choose from the default horizontal slider or a vertical one you drag from the bottom of the screen. Available in secure mode or customized mode-
• secure mode - display the utility lockscreen on top of the pattern lockscreen so you can control music & preview notifications in one wakeup even while locked down with your pattern. Exit this lockscreen by pressing the back key, then completing your pattern. No button customization is available in secure mode.
• custom mode - customize Power, Camera, slider-open, keypad buttons, & volume keys to choose which will remain locked, wakeup the utility lockscreen, or skip it for instant unlock.
• simple lockscreen disabled mode - no customization, just exits the lockscreen anytime it would normally be shown.
• in the non-secure modes (custom & simple), pattern security will be disabled at the time myLock is started. You can choose an idle timeout if you would like pattern security to turn on again after a number of minutes idle, disabling myLock until the pattern is unlocked.

The stay awake and shake options should also be integrated as global preferences available to any of the modes.

Requests for having the slide to unlock as an option in the custom lockscreen

I was using a palm pre the other day (co-worker got one) and I liked how their unlock slider works just like a design idea I had earlier while I was still only brainstorming features- the slider is radial so you grab it from the very middle of the screen at the bottom, and slide it up past a boundary. You can slide whatever direction is natural for your thumb, as long as you take it far enough from the start point and cross the boundary, you unlock. My idea for a shortcut launcher that worked exactly the same was one of the earliest ideas I had with myLock.

The idea was to touch the android starting at the bottom middle of the lockscreen (and keep your finger there) to display the shortcuts, and slide it to any one of them to unlock while launching the app. I shelved the idea after it occurred to me that we could just let app shortcut icons be placed onto the custom lockscreen or just let the homescreen exist with shortcuts, with no lockscreen at all.

So when I do the slider I want to make the myLock version to take advantage of that idea, minus shortcut launching, but also use the source code from the existing unlock slider to provide the default one also as an option. The a3 feature release probably won't have either, making it so the back & home touch keys do unlock when you have awakened the custom lockscreen.

New alpha 3 (and beyond) to-do list

The 0204 revision illustrates where I am at with the solid Android 2.0 optimized lockscreen replacement. I have fixed every implementation bug I came across that at first made me think that it might not be feasible to create a replacement lockscreen.

This revision demonstrates the power key and slider open lockscreen skip. While it is capable of any button wakeup or unlock, and also shake wake or unlock, I don't have those options implemented yet. The custom lockscreen only displays a message at the moment and would allow the notification bar to be used when awake. If you ever see a delay, it is due to the load time of the app you are unlocking into. Example, I see the lockscreen for 1 second when I am unlocking into twidroid.

Here's what remains to be done to consider the alpha 3 feature version ready for market release. I plan to get it into the market and go one update at a time into beta. These are just the loose ends that I need to get done, not things I need to test/learn how to do-

• Finish implementing the shake option and stay awake setting into the custom lockscreen.
• Implement button customization settings screen, where you can specify a functionality for each side key (locked, wake lockscreen, or skip lockscreen), and choose whether you want the slider to cause unlock or remain locked, and whether keypad buttons should be kept locked or do unlock when the slider is open

Here's some next priorities that will bridge the gap to beta:

• Add polished looking clock for the lockscreen itself. I really wanted to place small brightness and vibrate mode toggles somewhere on the clock display, one on each side seems feasible. This element will be a widget, but will be default in the lockscreen until full widget customization is implemented.
• Slide to unlock interface- optional, it has been requested. Without it, home key and/or back key can be used to unlock the awake lockscreen.
• Get the volume keys configured to let music be controlled while screen is asleep. A possible addition would be to allow camera key to pause or advance track, also.
• Create the pattern mode idle timeout allowing myLock to disable itself if left asleep for a user-specified amount of time

I am very pleased with the response and interaction from users out there; this has kept me excited about polishing this project. Keep the ideas coming.

If you get a specific conflict with any app or notice a behavior that always happens in response to something you do on your phone, please email me the details to mylockandroid at gmail, this will really help us improve for the feature alpha 3 release.

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.