Bluetooth: Fixed memory leak and file handles leak

After next pairing operation with same Bluetooth device
previous BT state machine never stopped, but new one is created.

Change-Id: Ic707d0b72fd98dc1cd9b485f337b7b6fb5a4e826
Signed-off-by: Anatolii Shuba <x0158321@ti.com>
Bluetooth: fixed MAC address appearing instead of friendly name

The bug occurs only for unknown devices that are discovered
for the very first time.
For some devices, the friendly name is not given immediately
but notified to the framework by a later ACTION_NAME_CHANGED event.
Sometimes the Name is updated in time but not the Alias,
that is temporarily equal to the MAC address of the device.
The fix consists in reading the Name before the Alias,
and resorting to this one only when the name is null,
as it is supposed to be.

Change-Id: If3029b44a95698fa6660bb8cf522a7c8c06a2d37
Author: Raffaele Aquilone <raffaelex.aquilone@intel.com>
Signed-off-by: Raffaele Aquilone <raffaelex.aquilone@intel.com>
Signed-off-by: Shuo Gao <shuo.gao@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Author-tracking-BZ: 27197
Move NTP updates outside locks

When the ServerThread handles ACTION_SHUTDOWN intent it sometimes get
stuck on mStatsLock in NetworkStatsService.java.
0  com.android.server.net.NetworkStatsService$5.onReceive()
1  android.app.LoadedApk$ReceiverDispatcher$Args.run()
2  android.os.Handler.handleCallback()
3  android.os.Handler.dispatchMessage()
4  android.os.Looper.loop()
5  com.android.server.ServerThread.run()
This happens when the NetworkStats thread is already holding the
mStatsLock while updating NTP.
0  libcore.io.Posix.getaddrinfo()
1  libcore.io.ForwardingOs.getaddrinfo()
2  java.net.InetAddress.lookupHostByName()
3  java.net.InetAddress.getAllByNameImpl()
4  java.net.InetAddress.getByName()
5  android.net.SntpClient.requestTime()
6  android.util.NtpTrustedTime.forceRefresh()
7  com.android.server.net.NetworkStatsService.performPoll()
8  com.android.server.net.NetworkStatsService.access$100()
9  com.android.server.net.NetworkStatsService$2.onReceive()
10 android.app.LoadedApk$ReceiverDispatcher$Args.run()
11 android.os.Handler.handleCallback()
12 android.os.Handler.dispatchMessage()
13 android.os.Looper.loop()
14 android.os.HandlerThread.run()
Since the NTP update consists of several socket operations it may get
stuck long enough to trigger a System Server Watchdog even though the
socket timeout is set to 20 second.
Further, the NTP update doesn't actually need to be performed inside
the locks and an attempt to change this was made earlier, but the code
wasn't actually moved outside the locks.

Change-Id: Ib37a2b8c2d51a01adb7ff01764f82309433703f0
 WebViewCore: Fix the issue of wrong zoom density when opening web pages with overview mode disabled.

 On JellyBean browser, when pages opened
 with "open pages in overview" disabled and "Default zoom" option set to
 "Far" or "Close", the zoom density is not correct.

 The issue is caused by the wrong scale factor calculated when setup
 viewport. it is fixed to 1.5 in JB. whereas it should be different for
 different "Default zoom" setting.

 This Patch will fix this issue. it set the scale factor to the
 defaultzoomscale calculated considering zoom density. it also add
 adjust process to guarantee the zoom density is right after navigating
 page with specified viewport "target-densitydpi".

 Author: Zang Lin <lin.zang@intel.com>
 Signed-off-by: Jack Ren <jack.ren@intel.com>
 Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>

Change-Id: I68dd193457c40ce9eb73635297ce7bb61b373bac