Calling this a true “driving” condition would be a misnomer, as a number of other factors would actually be used to guess that the user was driving. This request would simply detect the speed at which the phone is moving.
There are two ways currently to detect when the phone is in a car: a car dock condition or a Bluetooth condition, both of which are available now as plug-ins on the Android Market.
We’ve been investigating an implementation for a “speed” condition, and we’re confident we can create a reliable and low-power consumption implementation. There are just a number of considerations to take into account before doing so. After reading all of the comments, it appears that there are several different goals that users have in mind. Let’s look at a few of them:
1. Power savings: some users want to enable Bluetooth in the car and disable Bluetooth everywhere else. Unfortunately a speed condition would consume far more power than Bluetooth, so users are much better off simply leaving Bluetooth on all the time. Scratch this one off the list.
2. Safety/regulatory: some users want to turn the ringer off while driving, due to distracted driving safety and regulatory considerations. For this, there are some considerations:
First, how quickly would users expect Locale to detect a change in speed? The more quickly Locale detects a change in speed, the greater the impact on battery life. If the “speed” condition drains the battery in 4 hours, it doesn’t do anyone any good. Based on our research, there may be up to a 10 minute delay before speed changes can be detected. Would such a delay reduce the usefulness of a speed condition?
What about the reverse? How quickly would users expect the driving condition to deactivate once they stopped driving? Would it be annoying that you wouldn’t receive phone calls for 10+ minutes after you got out of the car? And how would users expect this condition to behave in bumper-to-bumper traffic? If the phone is moving at a slow speed for a long period of time, the speed condition might deactivate.
3. Finally, there are probably some other creative uses for a speed condition besides just to detect driving… Let’s hear them!
Calling this a true “driving” condition would be a misnomer, as a number of other factors would actually be used to guess that the user was driving. This request would simply detect the speed at which the phone is moving.
There are two ways currently to detect when the phone is in a car: a car dock condition or a Bluetooth condition, both of which are available now as plug-ins on the Android Market.
We’ve been investigating an implementation for a “speed” condition, and we’re confident we can create a reliable and low-power consumption implementation. There are just a number of considerations to take into account before doing so. After reading all of the comments, it appears that there are several different goals that users have in mind. Let’s look at a few of them:
1. Power savings: some users want to enable Bluetooth in the car and disable Bluetooth… more
I would like a speed condition NOT to block calls . . . NOT to disable/enable Bluetooth, but to SIMPLY place the phone in either car dock mode or airplane mode automatically. I am unable to actually dock my phone in my automobile but I would like for it to automatically switch into car mode. I do not understand the necessity of changing the speed with which the phone's speed is detected when my GPS is turned on. I may always turn a Locale condition off, correct? I only wish to change the mode of my phone based on travel speed so I have simple and quick accessibility to my phone's touch screen in car or airplane mode without having to determine bluetooth settings and/or fumbling through my list of aps.