bluedroid: Fix build with gcc 4.8

In gcc 4.8, the warning for unused parameters is enabled by
default - causing -Werror to break the build.

Change-Id: Ifa4dbc6a7cfec0c82486906ecf3ed6d53a550c3f
Credits: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>

Conflicts:
	gki/Android.mk
	main/Android.mk

Signed-off-by: dragon <dragon7780@hotmail.nl>
Fix bug in PAN code where no new PAN connections can be made.

If you call PAN_connect() followed quickly by PAN_disconnect(),
you won't be able to establish any additional PANU connections.
This happens because the connection never has a chance to make
it into PAN_STATE_CONNECTED and num_conns only gets decremented
if you disconnect in the connected state. As a result, subsequent
calls to connect will fail because the stack still believes there
to be an existing connection.

Change-Id: Id24873828ca4f517496cb19a44993d0e8e837a1e
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>
Fix BT failed to enable issue.

When BT startup, bt_hc_worker thread will send BT_EVT_PRELOAD_CMPL
to btu_task. However in bte_main_enable, it first calls
bte_hci_enable(), then creates btu_task. So it may send BT_EVT_PRELOAD_CMPL
before btu_task created. Change creating btu_task before call bte_hci_enable
to make sure btu_task already created successfully before send
BT_EVT_PRELOAD_CMPL

Change-Id: I2a784234e0fcf3a95743978f2a8c60aa30fd83be
Author: Tan Jingjing <jjtan@marvell.com>
Signed-off-by: yuwan@marvell.com <yuwang19860130@gmail.com>
Fix uipc.c to never pass -1 to FD_ISSET.

The behavior of FD_ISSET when passed -1 is undefined.

I checked all calls of FD_SET and FD_CLR in this file, and they all
seem to be correctly guarded. None of the FD_ISSET calls were, so I
added a SAFE_FD_ISSET macro to return false when passed -1, which is
presumably what the callers intended.

This allows Bluetooth to be enabled on a device where the C library
aborts if passed any out of range fd.

Bug: 11047121
Change-Id: I261404a5a80884d5e9edab8beb3c93969113dc76