Version of Smart AutoClicker
all
Apk
PlayStore
Device brand and model
all
Version of your Android OS
all
Type
Smart scenario
Describe what happened?
Softlock
Describe what should have happened?
Due to the nature of the app, in certain edge cases, softlocks can occur from oversights. While they should be incredibly rare in real-world scenarios, they do happen and the app should design a specific fallback for when it DOES happen.
I suggest that pressing power button should always lead to Klick'r giving up the full screen click capture. Whether scenario settings are open, an action/condition is being captured/edited, or something else was capturing clicks. It can be a fallback way to instantly let Klick'r give up its control.
However, sometimes user might have unsaved changes on screen when it happens. That needs to be handled.
Further, where softlock is caused by a stuck or killed process (I'm not sure about the technical aspects of this one, so excuse any mistakes or incorrect assumptions made), maybe this wouldn't be helpful. But certainly, when a user triggers a power menu to turn off/restart device or it's the lock screen, Klick'r not blocking those might solve part of the problem as well. I had highlighted that part specifically in #927
Any other approaches to introduce a fail-safe are welcomed for discussion as well
Is it a duplicate?
Did you provide enough information?
Version of Smart AutoClicker
all
Apk
PlayStore
Device brand and model
all
Version of your Android OS
all
Type
Smart scenario
Describe what happened?
Softlock
Describe what should have happened?
Due to the nature of the app, in certain edge cases, softlocks can occur from oversights. While they should be incredibly rare in real-world scenarios, they do happen and the app should design a specific fallback for when it DOES happen.
I suggest that pressing power button should always lead to Klick'r giving up the full screen click capture. Whether scenario settings are open, an action/condition is being captured/edited, or something else was capturing clicks. It can be a fallback way to instantly let Klick'r give up its control.
However, sometimes user might have unsaved changes on screen when it happens. That needs to be handled.
Further, where softlock is caused by a stuck or killed process (I'm not sure about the technical aspects of this one, so excuse any mistakes or incorrect assumptions made), maybe this wouldn't be helpful. But certainly, when a user triggers a power menu to turn off/restart device or it's the lock screen, Klick'r not blocking those might solve part of the problem as well. I had highlighted that part specifically in #927
Any other approaches to introduce a fail-safe are welcomed for discussion as well
Is it a duplicate?
Did you provide enough information?