[Bug]: App block bypass

[nhfo]

Summary

Blocked app can be used if launched from home screen shortcut

Steps to Reproduce

1. Setup an app to be blocked
2. Try launch app from home screen shortcut
3. Try launch app from home screen shortcut again do this a few times if does not trigger the bug

Expected Behavior

If an app is blocked it should not be possible to use it.

Actual Behavior

Blocked app can be successfully launched and used within few attempts by using home screen shortcuts. It usually takes just two attempts.

Environment

OnePlus Nord CE 5G (stock android 11) DigiPaws 2.3-aplha-lite Fdroid build

Additional Context (optional)

No response

[teleyos]

I had the same thing happened to me and fixed it by either :

• turning off battery optimisation for the app
• launching the app once on device startup

[jdk-21]

I noticed that too. I think it happens because of a cooldown in the pressHome() method. @nethical6 is there a need for the cooldown? Or can we reduce it or implement a queue?

I don't think the blockers trigger the pressHome unnecessarily, because there is a duplicate detection at least for the AppBlocker. I don't know if this is different for the ViewBlocker, i didn't test that yet.

Another improvement would be to reset the lastPackage to "" after pressHome was triggered. This improves the behavior for slower bigger apps. Sometimes even without the cooldown, they still get opened.

[nethical6]

I noticed that too. I think it happens because of a cooldown in the pressHome() method. @nethical6 is there a need for the cooldown? Or can we reduce it or implement a queue?

I don't think the blockers trigger the pressHome unnecessarily, because there is a duplicate detection at least for the AppBlocker. I don't know if this is different for the ViewBlocker, i didn't test that yet.

Another improvement would be to reset the lastPackage to "" after pressHome was triggered. This improves the behavior for slower bigger apps. Sometimes even without the cooldown, they still get opened.

I've already explored the bug and tweaking cooldown makes no difference. it's more of because of the accessibility event type. the appblocker has a typeWindowChanged event registered, which sometimes doesn't give out events when an app is opened quickly. replacing the event in raw/appblockerconfig with typeWindowContentChanged will fix the bug. Altho The problem is, when user enables both viewblocker and appblocker, the memory consumption increases significantly so I just thought I'll fix it later. Would love to get your opinions on possible solutions!

[jdk-21]

I created a draft PR, so you can try it (#181). The issue you describe with the event not triggering didn't happen in my case. But I'm on a Pixel 9 Pro, so this may be different with lower powered devices. However I could see in the logging that pressHome got called but didn't trigger because of the cooldown and another problem was that the lastPackage variable didn't get reset in time. Therefore it got flagged as a duplicate. (You may need to add additional logs to observe it more clearly. I tried to keep the changes in the PR to a minimum.)

Those changes completely resolve the issue for me without switching to the other event type.

[PranavPurwar]

I noticed that too. I think it happens because of a cooldown in the pressHome() method. @nethical6 is there a need for the cooldown? Or can we reduce it or implement a queue? I don't think the blockers trigger the pressHome unnecessarily, because there is a duplicate detection at least for the AppBlocker. I don't know if this is different for the ViewBlocker, i didn't test that yet. Another improvement would be to reset the lastPackage to "" after pressHome was triggered. This improves the behavior for slower bigger apps. Sometimes even without the cooldown, they still get opened.

I've already explored the bug and tweaking cooldown makes no difference. it's more of because of the accessibility event type. the appblocker has a typeWindowChanged event registered, which sometimes doesn't give out events when an app is opened quickly. replacing the event in raw/appblockerconfig with typeWindowContentChanged will fix the bug. Altho The problem is, when user enables both viewblocker and appblocker, the memory consumption increases significantly so I just thought I'll fix it later. Would love to get your opinions on possible solutions!

I've found that using TYPE_WINDOW_STATE_CHANGED along with TYPE_WINDOWS_CHANGED works rather well for purposes like this. As for the memory issue, exiting the function early if the event does not belong to a restricted package name is the better choice. If the package on screen is a distracting one, you could use it in combination with TYPE_WINDOW_CONTENT_CHANGED to check the current class for aggressive detection.