want to understand the hazards of manipulating keyguard while display not on and unlocked

[electricpete]

I would like to understand the nature of the hazard we face if we ignored the developer’s warning and manipulated the keyguard without meeting requirement that display is on and unlocked.  

 

Of course, the basic desire for most people I think is to turn their keyguard off at known locations (home, work) and then turn it back on when they leave these locations, but if triggered by typical location contexts, the change might occur when the display is off or on/locked.

 

I assume the concern is that phone can become disabled requiring something like a factory reset to recover, is that correct?

 

If that’s the case, it is intimidating to even experiment.

 

Does the caution apply to turning Keyguard "on" or to turning Keyguard "off", or to both?

 

Does this arise from Android system thinking there is unwanted tampering going on? Or just some unpredictable behavior?

 

Is there some failsafe we might be able to build into our code to be able to reverse unwanted changes?  (for example on next reboot, put the keyguard back to previous state).

 

Note, I’m a Froyo user.  

 

For info, here are some of the warnings posted.

 

http://tasker.wikidot.com/delay-keyguard
Tasker Developer Note: in Android 2.0+, the Keyguard action should probably not be used unless the display is *on* and *unlocked*, so try this profile at your own risk.

 

http://tasker.dinglisch.net/userguide/en/help/ah_index.html

Keyguard

Whether the keyguard is enabled or disabled.

The keyguard is the dialog requiring some sort of unlock action when the device is turned on.

Note: while keyguard is disabled, your SIM pin unlock screen may disappear after a few seconds after a reboot.

WARNING: while keyguard is disabled, the 'lock pattern' mechanism is also disabled, so your phone is unprotected if it is lost. There is also the possibility of interference with other applications that manipulate the keyguard.

On Android 2.2+, this action should probably only be used when the device is on and unlocked, unless the unlock method in Android settings is set to None.

Side-effect: coming out of Airplane Mode with Keyguard disabled may leave the SIM unrecognized until Keyguard is toggled again.

 

http://tasker.wikidot.com/disable-keyguard-when-at-home 

The above was posted by Bruton on 14th January 2012, and whilst this may work well for some, others WILL experience problems with the Keyguard being activated whilst the display is off. For these people, I would suggest you install the Secure Settings plugin from the Market and, in the second profile, create an action that calls the 'Screen Dim, for 5 seconds' function in Secure Settings BEFORE setting the Keyguard on. You can then create a third action to Lock the screen, which will turn the display off again:

 

 

 

[electricpete]

I suppose the steps recommended by user sayling excerpted below (get secure settins and execute screen Dim for 5 seconds before adjusting keyguard, etc) is the safest approach ?

On Friday, July 6, 2012 6:40:11 PM UTC-5, electricpete wrote:

Is there some failsafe we might be able to build into our code to be able to reverse unwanted changes?  (for example on next reboot, put the keyguard back to previous state).

http://tasker.wikidot.com/disable-keyguard-when-at-home 

[electricpete]

I have now downloaded/ installed “security settings” from the market.  

I looked around in tasker and here’s what’s new after that installation:

State / Plugin / Secure Settings / Configuration / Edit /  .... then choices for failed login attempts and secret code

Task / Plugin / Secure Settings / Configuration / Edit / then choices:

Actions: Keyguard . Mobile Data, Run Command, Wake Device

Dev Admin Actions: Lock Device, Password Pin

Custom Rom Actions: LTE

I don’t see anything like Dim that was mentioned by sayling. Also, there is a lot written about admin permissions that I don’t understand.  Any suggestions what to do with this?  Maybe I can use the keyguard command direct from Security Settings... is it supposed to be safer?

[Cptnodegard]

Tasker's keyguard thing ended up being too unstable for me so I'm using Unlock With Wifi separately to handle that, and it works flawlessly every time. 

[electricpete]

Thanks. I downloded that program and it worked pretty well.  It may be my permanent solution if I can't do much with Tasker.

But I'd still like to try with tasker so I can do it the way I want. For instance I still want a toggle widget so I can remove keyguard when I'm in the supermarket pulling out my phone to check my shopping list every 5 minutes.

You mentioned it's "unstable". I take it that means it doesn't do what was intended.   From looking at the vast number of threads on Keyguard I gather it's not easy and perhaps highly dependent on the phone and the Android OS version.

I've got time to experiment to see if I can do what I want.  

** My real question: do you think there is a hazard of bricking my phone if I disregard the specific caution mentioned in user manual, specifically if I execute Keyguard command while display is off or locked ?

[Cptnodegard]

By unstable I mean that it would sometimes lock the phone when it shouldn't, then not unlock it when it should, etc. Don't think there's a hazard of bricking anything, I threw the warning out the window when I tried it. I think it's more of a "might not work" kind of a warning. 

As for your supermarket thing, UWW has a delay setting so you could set the delay to e.g. 10 minutes. That means it locks 10 minutes after the screen turns off. 

[sayling]

Screen Dim is under the 'Wake' command in Secure Settings

On Saturday, 7 July 2012 01:25:17 UTC+1, electricpete wrote:
> I have now downloaded/ installed “security settings” from the market.  </p>

> I looked around in tasker and here’s what’s
> new after that installation:

> </p>

>
>
> State / Plugin / Secure Settings / Configuration / Edit /  .... then choices for failed login attempts

> and secret code</p>

>
>
>
>
>
> Task / Plugin / Secure Settings / Configuration / Edit /

> then choices:</p>
>
>
> Actions: Keyguard . Mobile Data, Run Command, Wake Device</p>
>
>
> Dev Admin Actions: Lock Device, Password Pin</p>
>
>
> Custom Rom Actions: LTE</p>

>
>
> I don’t see anything like Dim that was mentioned by sayling. Also, there is a lot written about admin permissions that I

> don’t understand.  <span style="font-family:&#39;Times New Roman&#39;;font-size:12pt">Any suggestions what to do with this?  Maybe I can use the keyguard command direct from Security Settings... is it supposed to be safer?</span></p>
> <font face="Times New Roman" size="3">
> </font>
> On Friday, July 6, 2012 7:08:32 PM UTC-5, electricpete wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I suppose the steps recommended by user sayling excerpted below (get secure settins and execute screen Dim for 5 seconds before adjusting keyguard, etc) is the safest approach ?
>
> On Friday, July 6, 2012 6:40:11 PM UTC-5, electricpete wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
> <b style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:small"><i>Is there some failsafe we might be able to build into our

> code to be able to reverse unwanted changes? 

> (for example on next reboot, put the keyguard back to previous state).</i></b>
> </p>
>
>
> <font size="2" color="#000000" face="arial, sans-serif"><b><i><a href="http://tasker.wikidot.com/disable-keyguard-when-at-home" target="_blank">http://tasker.wikidot.com/<WBR>disable-keyguard-when-at-home</a></i></b></font><b style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:small;background-color:rgb(51,119,204)"><i> </i></b>
> </p><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
> <span style="background-color:rgb(0,255,255)"><font size="2" face="arial, sans-serif"><b><i><font color="#000000">The above was posted by Bruton on 14th January 2012, and whilst this

> may work well for some, others WILL experience problems with the Keyguard being
> activated whilst the display is off. For these people, I would suggest you

> install the</font><span><font color="#cc0000"> </font></span></i></b></font><font color="#cc0000"><a href="https://market.android.com/details?id=com.intangibleobject.securesettings.plugin" target="_blank"><span style="background-repeat:initial initial">Secure
> Settings</span></a><span><span style="background-repeat:initial initial"> </span></span></font></span><span style="background-repeat:initial initial"><span style="background-color:rgb(0,255,255)">plugin from the
> Market and, in the second profile, create an action that calls the &#39;Screen Dim,
> for 5 seconds&#39; function in Secure Settings BEFORE setting the Keyguard on. You

> can then create a third action to Lock the screen, which will turn the display

> off again:</span><span style="background-color:rgb(51,119,204)"></span></span></p>
>
> </p></blockquote>
>
>
>
>
>
>
> <font size="2" color="#000000"><b><i><font face="arial, sans-serif"> </font></i></b></font></p>
>
>
> <font size="2" color="#000000"><b><i> </i></b></font></p>
>
>
> <font size="2" color="#000000"><b><i> </i></b></font></p></blockquote></div></blockquote></div>

[sayling]

On FroYo, you will be fine. The problem starts if you upgrade to ICS :(

As for what can go wrong by enabling the keyguard while the device is off... sometimes - and not every time, hence reports of 'unpredictable' - you may find it difficult to actually unlock the phone INITIALLY. But, in my experience, manually turning the screen off with a tap of your power/on/off button when - and if - the situation occurs, then turning the screen back on, will overcome the issue. If it doesn't, pressing your Home key will often enable you to enter your unlock pattern/pin/code successfully, If all that fails, powering off and powering on again (worst case scenario, pulling the battery out) will solve the problem.

But the easiest way to solve the problem is to ensure it doesn't occur in the first place - and that's why I would recommend having an action, using Secure Settings, to Wake the Device, setting Screen Dim to 2 seconds (the minimum) and then re-enabling the Keyguard (I used Tasker's action for this) before running the System Lock action in Tasker (which shuts the screen off).

As for disabling the Keyguard, I considered it a wise move to force me to at least unlock the device manually first before disabling the keyguard, when the condition of being at home/work while charging/at my brother's home/round my mother-in-law's is met, and that involves the screen being on for me to unlock the device. Thus disabling the keyguard when getting to one of those places WHILST the screen is OFF never became an issue.

With ICS, there seems to be a bug that overrides whatever Tasker is trying to do and enables the Keyguard whenever a Notification is clicked (ie to read and incoming mail notification, access Tasker from the notification list, etc). There appears to be a work round/solution if you are on a rooted phone with AOKP, but I'm on stock ROM so it doesn't work for me.

I'll have to have a look at Andreas's suggestion for myself, though! For you, electricPete - you should be good to go with Tasker and Secure Settings (in fact, you may not need Secure Settings! If I recall correctly, that only became necessary from GingerBread onwards!!)

On Saturday, 7 July 2012 07:19:38 UTC+1, electricpete wrote:
> Thanks. I downloded that program and it worked pretty well.  It may be my permanent solution if I can&#39;t do much with Tasker.
>
> </div>
> But I&#39;d still like to try with tasker so I can do it the way I want. For instance I still want a toggle widget so I can remove keyguard when I&#39;m in the supermarket pulling out my phone to check my shopping list every 5 minutes.</div>
>
> </div>
> You mentioned it&#39;s &quot;unstable&quot;. I take it that means it doesn&#39;t do what was intended.   From looking at the vast number of threads on Keyguard I gather it&#39;s not easy and perhaps highly dependent on the phone and the Android OS version.
> </div>
>
> </div>
> I&#39;ve got time to experiment to see if I can do what I want.  </div>
>
> </div>
> ** My real question: do you think there is a hazard of bricking my phone if I disregard the specific caution mentioned in user manual, specifically if I execute Keyguard command while display is off or locked ?</div>
>
> </div>
>
> </div>
>
> </div>
>
>
> On Friday, July 6, 2012 10:54:33 PM UTC-5, Cptnodegard wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Tasker&#39;s keyguard thing ended up being too unstable for me so I&#39;m using Unlock With Wifi separately to handle that, and it works flawlessly every time. </blockquote></div>

[electricpete]

Thanks Cptnodegard - that gives me a little confidence.

Thanks sayling. I'm going to try to build my setup following those instructions.  Looking at the Wiki you have obviously spent a lot of time on this.  

You mentioned that for disabling, you want the user to key in after he gets home and before you disable the keyguard. That's a great idea for security.  I'm thinking about how to accomplish it. 

One way would be expect the user to push a widget once he has keyed in.   If the widget sees that it has been launched while "at home", then it unlocks the keyguard.

(Later when user leaves home, a timer starts for locking).  

Out of curiosity, did you have in mind some other way to check for user keying in that first time? 

[sayling]

Regarding a "way to check for user keying in that first time " - if the phone is locked when they get home, the moment the screen comes on they will HAVE to key in their chosen method of security anyway :D

Have you looked at some of the other wiki entries regarding Keyguard Enablers/Disablers? You could have a peep at this one;)

[electricpete]

Thanks, I actually did study that one that you wrote quite a bit and plan to use roughly the same sequence to turn keyguard on, plus add the pluging/secure settings / configuration/wake / Dim 2 seconds before turning KEYGUARD on as you later suggested.

As far as turning Keyguard off, it seems we have only three choices:

1 - Do it automatically based on arriving home, in which case we need to be concerned about unknown effects if it occurs automatically while the display is off.

2 - Require the user to press some widget (while at home) to initiate the unlock (which he must be logged in to accomplish)

3 - Some way to sense if the user has typed in the key after arriving home, so that the keyguard then can be automatically disabled without further action from the user.

I'm leaning toward 2.  I don't think there is a 3.   Is there a 4 that I missed?

[electricpete]

Sorry, 1 was not a good option for security reasons (not concerns about changing while display off, which we could have resolved using similar approach as you suggested for keyguard on).

 The choice is really 2 or 3. 

[electricpete]

I just noticed there is an event for "Display Unlocked".  I can use  that combined with location "at home"  to accomplish approach 3. Therefore disregard my recent questions about the first unlock.

Thanks for your help.  The idea to waken the device using dim is good and puts my mind at east about bricking and apparently is required to make it work at all.

My goal is somewhat ambitious (For me) in terms of the logic:  I think I'm getting close. Will post results.

Thanks again.

[electricpete]

Thanks again for the insights you guys have shared.

I think I have success.   I haven’t invented anything new, but for me it is an achievement because the logic to meet my requirements is complex (for me anyway). But through all my testing so far (manipulating the variables to simulate leaving/arriving etc in all combinations I could think of), it works exactly as intended. . I will report results after a few weeks of real world use

 Unfortunately, despite my best efforts at documentation, it probably looks like spaghetti code (I wonder if I’ll be able to understand it six months from now).  I’m sharing it with the forum for what little it’s worth. Feel free to ignore it (my feelings won’t be hurt). If it triggers any thoughts of  better ways to do things or to document things, please let me know.

(By the way, is there a way to get rid of those label numbers added during export of tasks and profiles?)

 

Requirements:

A.     Want auto-disable keyguard at home and auto-enable after 15-minute time delay on the road.

B.     If I use my phone intermittently during the countdown period, I want the timer to be reset so that it begins counting all over again when I am finally done (timer will only enable keyguard when 15-minutes of  CONTINUOS display-off period occurs after I leave home)

C.   A toggle widget to indicate locked/unlocked status.  Additionally, the toggle widget provides limited manual control but ONLY in a direction which is at least as secure as the automatic behavior.  Specifically, the toggle can enable keyguard  manually whenver we want (at home or on the road).  And the toggle can disable keyguard, but the timer will still start it’s inevitable countdown whenever the display is off for 15 minutes on the road .

 

Trick for resetting or cancelling timer:

The heart of the code is task KGTimeoutTask including a timer which will enable keyguard when it finishes counting down.   This collision handling for this KGTimeout task is specified as “abort existing task” which means any new call to the task wipes out all the old timer tasks.  This enables us to reset the timer (when occurs when %par1=KgTimerEnable is passed to the task) or to simply get rid of the timer (when @par1 = KgTimerAbort is passed to the task).   .

 

Special Variables:

%DISPLAYSTATUS (on or off) is managed by the continuously-running profiles DispOn and DispOff.  Just a conventient way to convert the available Display on/off events into a DISPLAYSTATUS on/off state.

 

%AtHome (1 or 0) is managed by the continuously-running profile “Home”.  There are many ways to test for being at home/away of course and this is just one that works for me.  There are a few extra steps included in profile home (beyond toggling %AtHome variable) that support this KG management  (for example Home Exit task activates the timer routine).

 

 

Profiles:

Home, DispOn, DispOff all discussed above under “Special Variables”

 

CheckFirstUnlockHome – Normally this profile is disabled. Enabled only when HomeProfile senses arrival at home.  Looks for first Unlocking to occur at home and when it does, the KG is unlocked,  all timers cancelled, and the profile disables itself  (it is only active during the time it needs to be).

 

CheckDispDuringWait – Normally this profile is disabled.  Enabled only when KgTimerTask starts it’s timer.  It looks for display turnon during this countdown period, in which case it resets the timer and disables itself.  If no turn-on occurs, this profile will be disabled when the timer times out  (it is only active during the time it needs to be).

 

Tasks: 

Task KgTimeoutTask – discussed above under “trick for resetting/cancelling the timer.  Note also the timer does not ever begin until the display is sensed as off (“wait until” statement depending on the value of DISPLAYSTATUS).   Just before the 15-minute timer is activated, the CheckDispDuringWait is activated to check for display coming on during counting (which means we need to re-enter the counter routine and wait for the display to go off).  Most importantly, the suggestions from Sayling are used to successfully enable Keyguard with display initially off.

Task KGWidget is very similar to the “Keyboard Toggle Widget” shown in the wiki stepthroughs, with extra steps to abort any timer tasks when KG is toggled to on (you’re safe, who needs a timer) and to start a timer when KG is toggled to off while on the road.

 

 

Code:

 

 

Profile: DispOn (75)

Event: Display On

Enter: Anon (76)

<Variable used by kg>

A1: Variable Set [ Name:%DISPLAYSTATUS To:on Do Maths:Off Append:Off ]

 

Profile: DispOff (77)

Event: Display Off
Enter: Anon (78)
<Variable used by kg>
A1: Variable Set [ Name:%DISPLAYSTATUS To:off Do Maths:Off Append:Off ] 

 

 

Profile: Home (21)

State: Cell Near [ Cell Tower / Last Signal:GSM:XXXXX.YYYZZZZZ / 6

GSM:XXXXX.YYYZZZZZ / 0

GSM:XXXXX.YYYZZZZZ / 0

GSM:XXXXX.YYYZZZZZ / 0 ]

Enter: Anon (61)

A1: Mobile Data [ Set:Off ]

A2: Notify [ Title:Home-data off Text: Icon:<icon> Number:0 Permanent:Off ]

A3: Variable Set [ Name:%AtHome To:1 Do Maths:Off Append:Off ]

<Kill any old timer>

A4: Perform Task [ Name:KgTimeoutTask Stop:Off Priority:5 Parameter 1 (%par1):KgTimerAbort Parameter 2 (%par2): Return Value Variable: ]

<enable monitoring for first unlock>

A5: Profile Status [ Name:CheckFirstUnlockHome Set:On ]

Exit: Anon (62)

<If avoids false leave-home triggers due to cell signal. wifii is always out of range before leave home>

A1: If [ %WIFII !~ *connect* ]

A2: WiFi [ Set:Off ]

A3: Notify [ Title:Lv Home Wifi Off Text: Icon:<icon> Number:0 Permanent:Off ]

A4: Variable Set [ Name:%AtHome To:0 Do Maths:Off Append:Off ]

A5: Perform Task [ Name:KgTimeoutTask Stop:Off Priority:5 Parameter 1 (%par1):KgTimerEnable Parameter 2 (%par2): Return Value Variable: ]

A6: End If

 

Profile: CheckDispDuringWait (54)

Event: Display On

Enter: Anon (55)

<Reset timer>

A1: Perform Task [ Name:KgTimeoutTask Stop:Off Priority:5 Parameter 1 (%par1):KgTimerEnable Parameter 2 (%par2): Return Value Variable: ]

<Disable myself>

A2: Profile Status [ Name:CheckDispDuringWait Set:Off ]

 

Profile: CheckFirstUnlockHome (57)

Event: Display Unlocked

Enter: Anon (60)

<Abort any timer>

A1: Perform Task [ Name:KgTimeoutTask Stop:Off Priority:5 Parameter 1 (%par1):KgTimerAbort Parameter 2 (%par2): Return Value Variable: ]

<Icon unlocked>

A2: Set Widget Icon [ Name:KGWIDGET Icon:<icon> ]

A3: Keyguard [ Set:Off ]

<disable myself>

A4: Profile Status [ Name:CheckFirstUnlockHome Set:Off ]

 

Task: KgTimeoutTask (67)

A1: If [ %par1 ~ *abort* ]

<abort if signaled by caller...deletes any previous timer>

A2: Stop [ With Error:Off ]

A3: End If

 

<Wait for display udf condition, checking every minute>

A4: Wait Until [ MS:0 Seconds:0 Minutes:1 Hours:0 Days:0 ] If [ %DISPLAYSTATUS ~ off ]

<Enable profile which will interrupt the wait if display goes back on.>

A5: Profile Status [ Name:CheckDispDuringWait Set:On ]

<Variable for debug check only, can delete>

A6: Variable Set [ Name:%LAST_KG_TIMERSET To:%DATE %TIME Do Maths:Off Append:Off ]

<this is the timer wait period>

A7: Wait [ MS:0 Seconds:0 Minutes:15 Hours:0 Days:0 ]

<On timer completion, check display still off (should be)>

A8: If [ %DISPLAYSTATUS ~ off ]

A9: Secure Settings [ Configuration:Screen Dim

2 Seconds ]

A10: Keyguard [ Set:On ]

A11: Turn On

<Icon,locked>

A12: Set Widget Icon [ Name:KGWIDGET Icon:<icon> ]

A13: System Lock

 

<Only if somehow display on at end of timer (should not occur)>

A14: Else

<start timer all over again>

A15: Perform Task [ Name:KgTimeoutTask Stop:Off Priority:5 Parameter 1 (%par1):KgTimerEnabled Parameter 2 (%par2): Return Value Variable: ]

A16: End If

<cleanup added after exporting:>

A17: Profile Status [ Name:CheckDispDuringWait Set:Off ] 

 

Task: KGWIDGET (73)

A1: Keyguard [ Set:Toggle ]

<may not be necessary, but wait a second>

A2: Wait [ MS:0 Seconds:1 Minutes:0 Hours:0 Days:0 ]

<Toggled from on to off>

A3: If [ %KEYG ~ off ]

<Show unlocked icon>

A4: Set Widget Icon [ Name:KGWIDGET Icon:<icon> ]

<If not home then set timer>

A5: If [ %AtHome !~ 1 ]

<Call timer, enabled>

A6: Perform Task [ Name:KgTimeoutTask Stop:Off Priority:5 Parameter 1 (%par1):KgTimerEnabled Parameter 2 (%par2): Return Value Variable: ]

A7: End If

<Toggled from off to on>

A8: Else

<Show locked icon>

A9: Set Widget Icon [ Name:KGWIDGET Icon:<icon> ]

<Abort any timer>

A10: Perform Task [ Name:KgTimeoutTask Stop:Off Priority:5 Parameter 1 (%par1):KgTimerAbort Parameter 2 (%par2): Return Value Variable: ]

A11: End If 

[electricpete]

You all probably should not waste a lot of time reviewing what I posted below. Let me make any changes during my two weak trial period and report back.

 Here are a few things I’ll change:

1 – (editorical) I was a little sloppy on terminology (used locked/unlocked many places where I meant KG on/off).

2 - The order of the two tasks within CheckDispDuringWait profile needs to be reversed from what was posted below. 

In the old way, the  CheckDispDuringWait profile  would sit and wait for the timer task to finish.  Results seem unpredictable and the timer was not being reset when I expected.

In the new way, the profile completes as soon as it passes control to the Timer task and is ready to be re-enabled immediately if necessary.    It also gives more of the results I expected.

On Friday, July 6, 2012 6:40:11 PM UTC-5, electricpete wrote:

[electricpete]

I also increased the priority of the  CheckDispDuringWait  task to 8 and decreased the priority of the timer task to 4.

One or the other of these changes helped it to be able to reset the timer every time the display turned on.

I'm done now. You won't hear any more from me on this subject for two weeks.

[Matt R]

Is there a reason you make your own %DISPLAYSTATUS variable instead of the built-in %SCREEN variable?

Matt

[electricpete]

Matt,

There was no reason at all except I didn't know about that variable...was looking for a built-in variable called “DISPLAY” and it never occurred to me to look for a variable called “SCREEN”.  

But I will certainly make that change now that I know.  That will save some juice from monitoring stuff I don’t need to, and also reduce the clutter of unneeded extra variables. 

Thanks for the suggestion.

By the way, I also added an important extra line to disable the CheckDispDuringWait profile in task KgTimeoutTask after step A8.  Also a few minor tweaks (ongoing) to try to make sure I have covered all possibilities of what the program might see.   Will post those in a week or two. 

[Steve Mills]

On Saturday, 7 July 2012 04:54:33 UTC+1, Cptnodegard wrote:
> Tasker&#39;s keyguard thing ended up being too unstable for me so I&#39;m using Unlock With Wifi separately to handle that, and it works flawlessly every time. 

I looked at that App but it has a problem with ICS. I think it is ICS that is causing the Tasker-based solution. The ICS problem appears to be something to do with clicking things in the Notification bar. I'm clicking Notification bar things all the time, so I guess I'm going to have to wait until this problem is resolved in ICS.

[Simon Ayling]

Same here. The app author acknowledges they can't deal with pattern unlocks under ICS, sadly.

Where does one report problems to Google anyway?

[electricpete]

Where to report to Google?

Big brother already knows everything you've ever typed on the internet! Bwahahaha.

Here is a list that was linked in the stickies:

http://code.google.com/p/android/issues/list? 

You can enter a new issue, or you can search for existing issue and vote to increase it's priority.

On Sunday, July 8, 2012 11:00:12 AM UTC-5, sayling wrote:

Same here. The app author acknowledges they can't deal with pattern unlocks under ICS, sadly.

Where does one report problems to Google anyway?

[electricpete]

If you search for Keyguard and order the results by inverse number of stars, it probably leads to the likely existing candidates

http://code.google.com/p/android/issues/list?can=2&q=KEYGUARD&sort=-stars&colspec=ID+Type+Status+Owner+Summary+Stars&cells=tiles 

Maybe 14246 (beats me).  You could certainly add your comments and votes to that one, it already has 12 stars priority.

[Cptnodegard]

And that, ladies and gentlemen, is why I'm not upgrading to ICS. I refuse to upgrade to a version of the OS that is broken. 

On Sunday, July 8, 2012 6:00:12 PM UTC+2, sayling wrote:

Same here. The app author acknowledges they can't deal with pattern unlocks under ICS, sadly.

Where does one report problems to Google anyway?

On Jul 8, 2012 4:50 PM, "Steve Millsrote:

[RudeboyX]

Password Lock switching works fine on ICS. I used to have issues on all versions of Android until I figured out one special step. (Select "None" for security before selecting "Pattern" or "PIN" lock in android settings. this ensures that when tasker disables your PIN/Pattern lock it reverts to no security.

eg, if you sellect PIN lock and then change it to PATTERN lock. Now use tasker to disable pattern lock. Android reverts to PIN which is a lock screen still. The PIN lock doesnt show but PATTERN lock remains as android Android reacts to this by not changing your PATTERN lock screen as its already on A lock screen.

Basically its telling android to dissable security and revert to security, hence no change happens. (it doesn't revert to no security)

CLEAR INSTRUCTIONS FOR WORKING LOCK SCREEN DISSABLING (SECURE SETTINGS PLUGIN REQUIRED AND SETUP)
1st - in your android settings under security, set your security to "None". (Reguired so that android knows what to switch to when you turn the lock screen off.)

2nd - in the same Android settings screen, select "Pattern" or "PIN" and set it up. (I use pattern)

3rd - setup a profile similar to the below. (switches lock screen off when connected to home wifi and back on again when you leave home. feel free to use your own trigger and add more steps to the tasks. Mine personally has all sorts of other steps like changing widget icons and flashing notifications etc)

Context:
WiFi ~ (matches) "YOUR HOME NETWORK NAME"

Enter Task:
1Secure Settings (plugin): "Wake": Screen and keyboard lights on: 3 seconds
2 Wait 1 second (task)
3 Secure Settings (plugin): "Pattern Lock" or "Password/PIN": OFF

Exit Task:
1Secure Settings (plugin): "Wake": screen and keyboard lights on:  3 seconds
2 Wait 1 second (task)
3 Secure Settings (plugin): "Pattern Lock" or "Password/PIN": ON

Now if you are at home and connected to wifi, simply save the profile and exit tasker. the lock should be disabled imidiatley (1 second or so)(May require unlocking once) so test it by pressing the power button on your pone, now press it again and the lock screen should not appear. now take a walk or power of your home wifi for a min. (Tasker default setting checks wifi every 5 min or so, so you may want to change this in taskers settings to make it more responsive (I use 120 seconds (2min)). Anyway the point is that your pin lock should re-enable once wifi disconnects.

One thing I have noticed is that dispite the secure settings option to "require password entry at least once before it will be disabled" being on or off, its seems to be perminantly on. i.e when you reconnect to your home network, the lock screen will still appear the first time you wake your phone. simply unlock it and it will not re-enable until you leave the house again. (security feature to stop thiefs bringing the phone near your home to unlock the phone).

Hope this clears up some of the screen lock issues people suffer from.

Regards
RBX

[sayling]

Damn, I thought you had it sorted. But this still doesn't seem to work on a stock ICS Samsung Galaxy S2. It may be that it falls over at the first hurdle?

The bit about selecting None before selecting Pattern - if I select None, Security shows as None. If I then select Pattern, it says Pattern is on. If I run the task (not test it, but physically run it from a tasker shortcut), even though Secure Settings says it's disabled and the tasker value for %KEYG is 'off', checking the Security Settings says that the Pattern lock is on. If I set that to None, then re-engage security through the Shortcut (or an event driven Profile), no Pattern is then required.

If I leave it at Pattern enabled in android settings, then disable it/set it to 'off' through Tasker and Secure Settings, it all works lovely - until I click on one of those pesky Notifications, at which point I need to enter the pattern

:(

[RudeboyX]

Sorry to hear your still having issues.

 

first off, I'am using an AOKP ROM of ICS (Resurrection Remix 2.5.1) but know I had it working with an earlier version of this ROM which was bassed on the Samsung ROM but could have been AOSP.

 

Secondly, have you installed the seceure settings "helper" through secure settings (requires root)

 

Thirdly, I found that Taskers variable %KEYG reported only for the keyguard (no security) and not the pattern lock (security)

 

I know that the notification bug is a real pain in the butt as I came from stock Gigerbread on the S2 with working lock toggle to ICS and was hit by the notification clicking problem.

 

It may be worth turning security off in android settings, powering off, remove battery for 10 seconds, (if you have CWM recovery clear cache and dalvik cache), reboot and then setup as above.

 

As an additional thought, does the keyguard (not pattern lock) ever get activated after the pattern lock is disabled? (shouldn't happen if you select "None" for android security prior to setting pattern lock). If it does alter the task as below.

 

Context:
WiFi ~ (matches) "YOUR HOME NETWORK NAME"

Enter Task:
1 Secure Settings (plugin): "Wake": Screen and keyboard lights on: 3 seconds

2 Wait 1 second (task)
3 Secure Settings (plugin): "Pattern Lock" or "Password/PIN": OFF

4 Disable keyguard (could try either taskers or secure settings option for this)

Exit Task:
1 Secure Settings (plugin): "Wake": screen and keyboard lights on: 3 seconds

2 Wait 1 second (task)

3 Secure Settings (plugin): "Pattern Lock" or "Password/PIN": ON (don't re-apply keyguard)

 

Hope you get it sorted. Although If you'r routed, I would recomend installing an AOKP ROM instead of stock. every little niggle that the Samsung ROM has with tasker is gone. I always struggled with app detection on the stock Samsung ROMS (%WIN) with profiles never getting activated.

 

Regards

RBX

[Simon Ayling]

Stock and non-rooted, unfortunately - and stuck like that :(

[RudeboyX]

Then thats where your problem lies. The galaxy S2 requires secure settings to achieve many a secure function like Pattern lock toggle etc. Secure settings requires that your phone be rooted so that the helper app can be installed to the system partition of your phone. If you dont install the helper app, then secure settings offers you nothing more than what Tasker can do allready.

RBX

[Simon Ayling]

Not strictly true, as there are some functions in Secure Settings that don't require root and Tasker doesn't do (screen on, for example) - but that's just minor semantics and nothing for us to argue about ;)

[Michael Yeager]

I just discovered thanks to someone else that I don't have to disable the Keyguard at all. I can clear and set my PIN and it works just fine. Might work the same for you...

On Monday, January 7, 2013 4:58:44 PM UTC-5, tobybe...@gmail.com wrote:

RudeboyX, you legend. I've been trying all over the internet to find a solution, and the setting 'None' before whatever security procedure, worked perfectly. 

Cheers