This is a new implementation of TTY support.
Previous implementation in commit aead64def1fe58c95c086a0ca00cf0b13fa32ef1 is reverted.
The new method does not rely any more on the kernel headset driver to send a UEvent containing
current TTY mode.
Handle TTY mode change events received by HeadsetObserver and send information down to AudioHardware with AudioManager.setParameters()
Use setting "tty_mode_uses_heaset_events" in core config.xml to indicate if the product uses this particular
method of indicating the TTY mode change.
The problem occurs if the delay between the headset removal and insertion is less than one second.
In this case, as the headset disconnection intent is broadcast with a 1 second delay to allow music to pause
before updating the route, the connection intent is broadcast before and is ignored, leaving the system
in a state where the headset is considered disconnected.
The fix consists in inserting a delay before broadcasting the connection intent if a disconnection
intent is pending broadcast.
The problem is due to spurious headset connection indications received from event observer when a 3.5mm headset w/o mic is connected.
In this particular case, The HeadsetObserver first received a valid indication of headset with mic connection, followed by a headset with mic disconnection and finally a headset w/o mic connection.
The HeadsetObserver delays the headset disconnection intent to leave time to music app to pause music before the output path is switched.
As the last headset w/o mic connection indication is received from the event observer before the intent corresponding to the spurious headset with mic disconnection is broadcast, the later is discarded. Results a state where the headset with mic is always considered as connected.
The fix consists in not canceling pending intents when a new headset state is received and carrying the HeadsetObserver state with the delayed message triggering the broacast of the disconnection intent.
The cause of the problem is that under certain circumstance the HeadsetObserver receives unexpected connection events. For instance,
when removing a bad quality 3.5mm stereo jack without mic the following events can be received:
1 connection of a headset with mic
2 removal of a headset with mic.
The result is that the no mic headset is never disconnected and audio policy manager considers it is still present. Then the music or downlink call audio is always routed to headset even if none is connected giving the impression that audio is lost, except whne you reconnect a headset of enable speaker phone.
The fix consists in adding more checks in HeadsetObserver to reject illegal transitions in headset state received from event observer.
The headset state indicated by HeadsetObserver in the broadcast intent ACTION_HEADSET_PLUG was not 0 or 1 as specified in the java doc but contained a bit field indicating the type of headset connected.
Modified HeadsetObserver to broacast a state conforming to java doc.
Added an extra to intent ACTION_HEADSET_PLUG to indicate if headset has a microphone or not.
Removed handling of non standard headset indications from HeadsetObserver.
Removed platform specific devices from output devices defined in AudioSystem.
Modified AudioService to use new ACTION_HEADSET_PLUG intent extra instead of bitfield in state.
Initial commit for review.
Integrated comments after patch set 1 review.
Fixed lockup in AudioFlinger::ThreadBase::exit()
Fixed lockup when playing tone with AudioPlocyService startTone()
