fixing droid proximity sensor with Screebl-like app
Hello @jwkennedy. Thanks for your observations that Screebl might be a solution to this issue.
Over the past few days I've gotten dozens of emails from frustrated users of Screebl that bought and downloaded the app with the hope that it would fix the problems with DROID that are being discussed in this thread. It turns out that Motorola is actually recommending that users download Screebl to solve the problem.
The unfortunate reality is that Screebl is NOT designed for this use case, as @jwkennedy correctly observes. In fact, Screebl is designed to keep the screen ON. It never ever turns the screen OFF. The way that the screen gets turned off when Screebl is installed and running is that Screebl releases its hold on something called a "wake-lock", which is what keeps the screen on. Once the wake lock is released, Android will turn the screen off after the system-configured screen timeout has expired.
It would certainly be possible for an app to monitor accelerometer readings and based on those readings lock the screen when a) in a call, and b) the phone is being held in certain orientations. The fly in the ointment here, however, is that it is not possible to invoke the standard Android lock screen and keyguard from any app. There is no API that provides for this -- it is not an allowed operation.
That being said, it may be possible to, in effect, write a custom "lock screen" activity that would turn off the screen, disable touch events, etc, while in a call. This lock could remain in effect until the phone returned to an orientation that was not associated with "in-call", or until the call ended. Keep in mind that some devices do NOT allow accelerometer readings to be consumed during a call. This would get in the way of using orientation as a metric for determining in-call activity. Not sure where DROID is w.r.t. accelerometer readings during a call.
Not sure if keyeslabs is going to be the one to tackle such an app. I've had users offer to pay me $50/each for a good implementation, but I don't know if we have the bandwidth at the moment given some other projects that are in the works. We'll see.
Hope this helps clarify Screebl's relationship to this particular DROID defect.
Hello @jwkennedy. Thanks for your observations that Screebl might be a solution to this issue.
Over the past few days I've gotten dozens of emails from frustrated users of Screebl that bought and downloaded the app with the hope that it would fix the problems with DROID that are being discussed in this thread. It turns out that Motorola is actually recommending that users download Screebl to solve the problem.
The unfortunate reality is that Screebl is NOT designed for this use case, as @jwkennedy correctly observes. In fact, Screebl is designed to keep the screen ON. It never ever turns the screen OFF. The way that the screen gets turned off when Screebl is installed and running is that Screebl releases its hold on something called a "wake-lock", which is what keeps the screen on. Once the wake lock is released, Android will turn the screen off after the system-configured screen timeout has expired.
It would certainly be possible for an app to monitor accelerometer readings and based on those readings lock the screen when a) in a call, and b) the phone is being held in certain orientations. The fly in the ointment here, however, is that it is not possible to invoke the standard Android lock screen and keyguard from any app. There is no API that provides for this -- it is not an allowed operation.
That being said, it may be possible to, in effect, write a custom "lock screen" activity that would turn off the screen, disable touch events, etc, while in a call. This lock could remain in effect until the phone returned to an orientation that was not associated with "in-call", or until the call ended. Keep in mind that some devices do NOT allow accelerometer readings to be consumed during a call. This would get in the way of using orientation as a metric for determining in-call activity. Not sure where DROID is w.r.t. accelerometer readings during a call.
Not sure if keyeslabs is going to be the one to tackle such an app. I've had users offer to pay me $50/each for a good implementation, but I don't know if we have the bandwidth at the moment given some other projects that are in the works. We'll see.
Hope this helps clarify Screebl's relationship to this particular DROID defect.