I tested this strange behavior only in my tablet, but I guess it happens in others too.
I tested this strange behavior only in my tablet, but I guess it happens in others too.
if(LL.isLocked())LL.unlock();
Just run this small piece of code in the screen on event.
It will says ‘the device is not unlocked’ even thought isLocked() return true.
Also, Pierre Hébert I want to know the exact (if possible) order of these events, and when the isLocked and isPaused change:
ScreenOn
ScreenOff
Resume of the lock screen
]]>(Next Post) A question for Pierre Hébert & the script gurus. »
D5 Creation
< ![CDATA[
This is because the “screen on” event is run in the context of the home screen, not the lockscreen, and as a consequence it cannot work. This is counter-intuitive but I am not sure I can change this. I will try to forward the request to the lockscreen in this specific case.
Events order is unknown because they are driven by the Android system. I cannot assert that screen on/off will happen before or after pause/resume, but chances are that they will, in practice, come in a fixed order. The locked state depends on the time needed by the system to create an activity, which may depends on the current system load, so it is not deterministic.
]]>
< ![CDATA[
And what about the resume of the lock screen triggered when you turn the screen off
From little test I made, this is the order I have
Turn the screen off
Turn off event
Resume of the lock screen(perhaps this was before, can’t remember now)
Turn screen on
Screen on event
Resume of the lock screen.
]]>
< ![CDATA[
In theory this could change… Screen on/off events are probably sent at a constant time (more or less) but pause/resume events may depends on variable factors. There can also be a sequence of pause/resume/pause in some situations.
]]>
< ![CDATA[
Pierre Hébert, I prefer to say this here.
Now I can use my script, thanks.
But just something more:
I need to know if, when the screen off event is launched, the screen is locked or not. Unfortunately it seems that the lock action is executed before the screen off event, and LL.isLocked() always return true in this context, no matter if it were locked before.
How difficult will be to change this?
More precisely: LL.isLocked() needs to return true only if the screen were turned off while locked. Otherwise it should return false.
]]>
< ![CDATA[
I turned the problem in every directions but I couldn’t find a solution. Screen state cannot be used to modify the isLocked result because the lockscreen can be activated upon another trigger, not depending on the screen state. The only workaround I can see now would be to have locked/unlocked event and compare the latest locked time with the screen off time. A short duration would mean the screen was unlocked.
]]>
< ![CDATA[
Don’t worry if it is too complicated, I just wanted to make a ‘unlock if you locked in less than X milliseconds’
Right now the code is this, you can test and even suggest a workaround 🙂 The problem is that without the islocked test you can bypass the lock screen just turning off and on again.
var milliseconds = 5000;
var event = LL.getEvent();
if(event.getSource()==”SCREEN_ON”){
if(event.getDate()-LL.getScriptTag()
}else{
if(!LL.isLocked()) LL.setScriptTag(event.getDate());
}
//Android.makeNewToast(event.getSource()+” “+LL.getScriptTag(),false).show();
]]>
< ![CDATA[
paused/resumed events could have been used for this, but unfortunately they are triggered twice during screen off (because the activity is restarted and Android triggers a full resume/pause cycle, no matter what the screen state is. As a consequence these events are useless, except if you skip some of them because they are too near.
I use this hack for the home key. This key cannot be caught by apps, but in case of the launcher it triggers some sort of short “suspend”, where the app is paused then resumed. When a resume is found less than 500ms, then the launcher assumes that the key has been pressed. Maybe some filtering like this can be used with paused/resumed events on the lock screen container
]]>
< ![CDATA[
Hmm, I’ll think about that.
Yes, I first thought about the resume/paused, and I discovered that ‘double event’. This bug report was because of it 😛
]]>
< ![CDATA[
True, but this bug was for once documented: http://www.pierrox.net/android/applications/lightning_launcher/help/topic.php?id=153. This is so infrequent that it is worth mentioning it…
]]>