Bluetooth losing HF connection to car-kit after 5 seconds

This patch adresses a change in bluetooth which causes a possible
loss of connection within 5 seconds after connecting.  This new
behavior appeared with android 4.2 (4.1.2 worked fine in this regard).

I traced down the disconnects to an BTA_AG_SVC_TOUT_EVT via a timer
that checks if a service connection was made within a few seconds.
Essentially bta_ag_svc_conn_open() was not called on AT+CMER because
android thought the car kit supported 3WAY but the car kit did not
set the 3WAY flag via AT commands and did not send AT+CHLD either.
Android otoh used the flag obtained by SDP and expected 3WAY behavior
and eventually disconnected when AT+CHLD did not arrive.

This may be a bordeline case, because in the Bluetooth Specification
(page 20), assuming service level initialization via SDP is only
mentioned on the HF side while there is no such mention (but could
probably be implied) on page 21 for the AG.

Fact is however, that the use of SDP features value for peer_features
is new since Android 4.2 and breaks existing good behavior on a BMW
2005/E46 car kit (navi professional). This kit never asks for AT+CHLD
and never via AT commands suggests it supports 3WAY (although it seems
to have the flag set via SDP).

Also, having essential behavior (like making the connection or not)
depend on circumstances that may be prone to race conditions, may be
a good reason to not use the SDP flag also (or at least masking out
the 3WAY bit when using it).

(An alternative approach could be to hook into bta_ag_timer_cback() and
when the timer exipres, but when also AT+CMER has been seen meanwhile,
to continue and assume a service level connection without 3WAY,
i.e. clearing the 3-way flags but calling bta_ag_svc_conn_open() anyway.)

Change-Id: I95dcdc5f46e7af723a655afd3d707764603c96c3
Signed-off-by: Markus Schmidt <shimodax@gmail.com>
(cherry picked from commit 662eaddd47bca1de03018fbcbe57ca2bfabaa5ac)

1 files changed, 18 insertions, 0 deletions

diff --git a/bta/ag/bta_ag_sdp.c b/bta/ag/bta_ag_sdp.c
index 0269258a2..cfddb7439 100644
--- a/bta/ag/bta_ag_sdp.c
+++ b/bta/ag/bta_ag_sdp.c
@@ -367,11 +367,29 @@ BOOLEAN bta_ag_sdp_find_attr(tBTA_AG_SCB *p_scb, tBTA_SERVICE_MASK service)
         {
             if ((p_attr = SDP_FindAttributeInRec(p_rec, ATTR_ID_SUPPORTED_FEATURES)) != NULL)
             {
+                /* Do not use the value as peer_features.
+                ** Reason is, that the service connection negotiation depends on the
+                ** BTA_AG_FEAT_3WAY feature (see the calling of bta_ag_svc_conn_open()
+                ** for BTA_AG_HF_CMD_CMER). A race condition could result in erratic
+                ** behavior.
+                **
+                ** Background: Using the attr_value for peer_feature was a change introduced
+                ** in android 4.2. That version triggered a number of bug-reports about
+                ** bluetooth being broken.
+                **
+                ** This problem was observed first hand on a BMW 2005/E46 car kit which does
+                ** not send AT+BRSF and behaves as if it would not support 3WAY. With the newly
+                ** introduced code for using attr_value as peer_feature the result was that
+                ** bluetooth connections to the car kit always terminated after 5 seconds
+                ** (via BTA_AG_SVC_TOUT_EVT).
+                */
+#if 0
                 /* Found attribute. Get value. */
                 /* There might be race condition between SDP and BRSF.  */
                 /* Do not update if we already received BRSF.           */
                 if (p_scb->peer_features == 0)
                     p_scb->peer_features = p_attr->attr_value.v.u16;
+#endif
             }
         }
         else    /* HSP */