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
Fix array shifting logic of updating bg devices list.

Assume there're bg devices [a, b, c], and a is removing. The code updates the
array to [b, c, c], which the right most remained element of bg_dev_list is not
cleared after shifting and makes it duplicated.

Change-Id: I048f6526a5de32aa82ef0eb22df7d5f8b937171b
Signed-off-by: Ting-Yu Chou <janus926@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>
Bluetooth: GAP: Update bonded device info immediately on NVRAM

As the new bt-if config updation have delay in writing items
to the NVRAM, some times there is a chance of not updating
incase of battery removal happens before the actual write onto
NVRAM.

As the bonded device info is important data to store, it will
update bonded info immediately onto NVRAM.

Change-Id: I9699c8225a77d9272420334b4c76b3c1df87e459
Bluetooth: fix sniff issue with multiple rfcomm connection in same ACL

When there are multiple rfcomm connection with same appid and peer bd
address, we were clearing jv pm control block in addition to closing
connection to service with registered app id. Since appid is common
across all the client and server app registed to jv. we were clearing
entire connection to service for this appid and peer bdadres which was
corrupting sniff logic, when another rfcomm connection exists with same
peer bdaddress. So avoiding closing of connection to the service when
multiple rfcomm connection exists in same ACL.

Change-Id: Id71ef5f7f0e00f1bda3b70a4826c31bef46caafc