Killing the app will bypass the lockpin if onlyBackgroundTimeout is true

[wesjpaul]

Condition:

• onlyBackgroundTimeout=true
• timeout > 0 (i.e. long enough to allow the app to be closed and reopened roughly > 5 seconds)

Killing the app while the lockscreen is visible will reset the timer allowing the user to reopen the app and bypass the lockscreen.

I have narrowed this down to AppLockImpl.java line 382 where setLastActiveMillis() is set if onlyBackgroundTimeout is true during onActivityPaused(). Since onActivityPaused() is called when the LockScreen is displayed this will trigger the setLastActiveMillis(). When the app is killed and relaunched the LockManager thinks the app had previously been unlocked and allows entry.

[oliveeyay]

Hello @wesjpaul
Are you using the last version in date?
I know the same problem was addressed in a previous issue, and I think we fixed it?
Is it possible that you use an older lib?

Thank you
Olivier

[wesjpaul]

Hi @OlivierG13

We are using version 1.9.4

compile ('com.github.orangegangsters:lollipin:1.9.4@aar'){ transitive=true }

[oliveeyay]

@wesjpaul
I think the problem is that you should exclude your custom "PinActivity" from the triggered activities.
appLock.addIgnoredActivity(PinActivity.class);

That way the onActivityPaused() is not calling setLastActiveMillis()
(Not super sure about this, it's from my memory ^^)

[wesjpaul]

@OlivierG13
We have done this. I believe the onActivityPaused is being called from our previous activity when the PinActivity is being created overtop.

I'll see if I can put together a demo project sometime today.

[oliveeyay]

@wesjpaul
I think there is a test for that specific case named testPinLockWithBackgroundTimeout
Did you try running the test suite on the library itself? (if you clone the library itself)
What device are you using?

Thank you for your help :)

[wesjpaul]

@OlivierG13
We have tested on a Nexus 5 and oneplus 3 so far. I will try running the test suites.

[wesjpaul]

@OlivierG13
Just ran the test suites and it appears the 'testPinLockWithBackgroundTimeout' test is failing. This was run on the OnePlus 3, 6.0.1.

junit.framework.ComparisonFailure: MainActivity expected:<...egangsters.lollipin.[Ma]inActivity> but was:<...egangsters.lollipin.[CustomP]inActivity>
at com.robotium.solo.Asserter.assertCurrentActivity(Asserter.java:68)
at com.robotium.solo.Solo.assertCurrentActivity(Solo.java:990)
at lollipin.orangegangsters.github.com.lollipin.functional.PinLockTest.testPinLockWithBackgroundTimeout(PinLockTest.java:255)
at android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:214)
at android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:199)
at android.test.ActivityInstrumentationTestCase2.runTest(ActivityInstrumentationTestCase2.java:192)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:191)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:176)
at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:555)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1985)
Tests ran to completion.

EDIT:

I have also been able to reproduce the problem in the demo app if I add these two settings to the CustomApplication.java class.

lockManager.getAppLock().setTimeout(1 * 30 * 1000);
lockManager.getAppLock().setOnlyBackgroundTimeout(true);

[oliveeyay]

Damn. It's maybe a particularity of the OnePlus, or of 6.x :(
The idea would be to not call setLastActiveMillis() on any activity if the password should be asked.

Would you be able to do that change on the library and do a pull request?
Otherwise I can try to fix it tomorrow maybe.

[oliveeyay]

@wesjpaul
The goal being to not break any other feature of the app of course, that's why we put some tests there to assess that there is no regressions and stuff.
Thanks :)

[wesjpaul]

@OlivierG13 Just tested it on a Galaxy S3 running 4.3 and the problem persists. If I have some time today I will look into a solution.

[oliveeyay]

@wesjpaul
Hummm then maybe a pull request broke the whole library :(
Cool, don't hesitate if you need anything.

[stannie]

@wesjpaul this issue was closed quite a while ago but we ran into it too on some of our devices and think the pull request in #157 Is fixing it.