This should make watches aware of a force disconnection for permanent device
removal making possible to remove any persistent data associate with the
device.
KEY_STOP is apparently only used by Sun keyboards while KEY_STOPCD is more
common. KEY_FASTFORWARD also maps better to the AVRCP fast forward key code.
It is necessary to make Device.Disconnect safe to be called, since some devices
were treating it as an unwanted disconnection and try to reconnect imediately
after it.
This make sure no entry is left on storage when removing a temporary and
make device_set_temporary usable for marking devices to be removed from
storage when disconnected.
This prevents overflows and audible artefacts for the audio files which
originally had loudness maximized. Music from audio CD disks is an
example of such files, see http://en.wikipedia.org/wiki/Loudness_war
In principle HFP 1.5 requires us to bring SCO up in the case of an
incoming call (before we start sending RING indications). However, it's
not safe to force it up ourselves in bluetoothd since there could be an
A2DP stream active which needs to be suspended first and the telephony
subsystem might want to do some extra initialization before enabling
SCO. This patch basicly leaves the responsibility of bringing up SCO to
an external entity but still leaves the hs->pending_ring flag on so that
we know to start sending RING indications when SCO finally goes up.
The new fragment will introduce device strings that can be given the BT
address of the headset as parameter. Also, they integrate 'plug' so that
they can be used with any application.
This replaces the old 'asound.conf' file which was much more limited.
Also since we now install 'bluetooth.conf' to /etc/alsa it is not a good
idea to simply call that file 'asound.conf'.
Please note that this will install the config fragment but not actually
enable it. For that some minor changes to the /etc/asoundrc as shipped
by the distro are necessary. It's up to the distributions to do this.
How that works in explained in the header of bluetooth.conf.
Application can give RFCOMM channel as pattern for Serial.Connect and
Serial.Disconnect, in case of no service matching the given channel it
wont trigger the channel discover proceeding directly to connection phase.
Getting the call indicator value right is actually pretty tricky. If we set it
to 1 in the first ->ACTIVE state transition then we need to change it to 0 when
we make the first transition that will result in the call becoming IDLE. As far
as I can see there are two possible such transitions: MT_RELEASE and
MO_RELEASE.
