WAI
Status Update
No update yet.
Comments
ha...@gmail.com
So they can leave the app if they don't like what it is doing. And there is no way
to enforce a permission on this.
to enforce a permission on this.
co...@gmail.com
"So they can leave the app if they don't like what it is doing."
That assumes they are still alive.
Android has the emergency call option available outside the lock screen for this very
reason -- expecting somebody to accurately enter their lock code in an emergency
situation is too much to ask. Similarly, expecting somebody to guess that the problem
is the app they are running (versus pressing the wrong button, or the phone/OS being
broken) in an emergency situation may be too much to ask. At least let them know that
there might be a problem here when they install the app.
"And there is no way to enforce a permission on this."
Would you care to place a wager on this?
Some piece of code, somewhere, is deciding to filter out KEYCODE_ENDCALL and
KEYCODE_HOME from the path that leads to onKeyDown() and kin. One would imagine that
there is some way to have that code invoke checkPermission() or the equivalent to
determine if android.permission.OVERRIDE_CALL_BUTTON is held and, if not, also filter
out KEYCODE_CALL.
That assumes they are still alive.
Android has the emergency call option available outside the lock screen for this very
reason -- expecting somebody to accurately enter their lock code in an emergency
situation is too much to ask. Similarly, expecting somebody to guess that the problem
is the app they are running (versus pressing the wrong button, or the phone/OS being
broken) in an emergency situation may be too much to ask. At least let them know that
there might be a problem here when they install the app.
"And there is no way to enforce a permission on this."
Would you care to place a wager on this?
Some piece of code, somewhere, is deciding to filter out KEYCODE_ENDCALL and
KEYCODE_HOME from the path that leads to onKeyDown() and kin. One would imagine that
there is some way to have that code invoke checkPermission() or the equivalent to
determine if android.permission.OVERRIDE_CALL_BUTTON is held and, if not, also filter
out KEYCODE_CALL.
Description
"Apps can intercept the call key to let the user press it when on a phone
number or other thing that makes sense to perform a call on."
However, this also means that apps can intercept KEYCODE_CALL to block
device functionality. In this case, Ms. Hackborn's comment is from a thread
where the OP wants to suppress the call key for no apparently good reason:
That is fine and a necessary side effect of enabling the feature Ms.
Hackborn cites. However, it does introduce some end user risks. Notably, if
apps can block the call key (by eating the event), users might get confused
when trying to place a call. In an emergency situation, they might not
figure out to press HOME, then CALL, in order to get past the
application-specific block, to then call 911 or the local equivalent.
Since I can't quite fathom how better to handle this, you might consider
requiring a permission to receive KEYCODE_CALL in onKeyDown() and related
callbacks (no permission = KEYCODE_CALL is treated like KEYCODE_HOME and
KEYCODE_ENDCALL). This at least alerts the user to the situation.