Move Bluetooth remove service record handler to the app main thread.
This removes the dependency of caller thread that constructs the
BluetoothAdapter singleton instance. The caller thread could stop while
BluetoothAdapter singleton exists but lose the handler context.
Make the BluetoothService.removeServiceRecord return quickly without
blocking on native call.
bug 4999443
Change-Id: I302534baa381f4aca8192e1e4a9ea21793b07ba6
On devices that do not require showing lock before unlock, we now only create
just the unlock screen. In addition to simplifying the code, this also
prevents keeping around a potentially unusued lock screen and saves ~1MB
in the system process on devices with only a secure lockscreen.
Change-Id: I533f2692b44a7991d4850cecc874c76166e7ce71
The interpretation of BT NREC by AudioFlinger to enable
or disable AEC and NS was wrong: NREC to ON (default) means
the phone (Audio Gateway) must enable local AEC and NS.
Change-Id: I88a264e7fc9831c43bbace4f6b585baec73f2006
There was a bug in an InputMethod app, where popups for the keys
would not pop-down again. The problem was that they were being
marked INVISIBLE, but the new invalidation logic noop'd the
invalidate() call that used to take place. Adding to that was logic
in setFlags() that only invalidated a parent for parents that are
instanceof ViewGroup. In this case, the parent is a ViewRootImpl.
Fix is to call invalidateChild() on the parent if it's not a ViewGroup.
Change-Id: I2c2352072d383cee1367ea7ee6c2207077721fd5
When we first ported wpa_supplicant 0.8, we had a work around
to fix the supplicant state change behavior from the driver.
Remove the work around since the driver behavior is fixed.
Bug: 5195278
Change-Id: I320f21ab01704931a3def6214b0cc40f214a688e
And fix associated changes from the settings.
With p2p_reconnect setting turned on, it means the p2p group can be
started without a group negotiation. Hence, handle p2p group started in
the P2pEnabledState
Also, reinvocation results in supplicant not reporting device address correctly.
Handle that until supplicant fix is fixed.
Bug: 5002384
Change-Id: I335f6e854acd6839f54da9b460b17ad7505b1098
Bug: 5220835
It is possible to call setProperty before webcore has initialized.
In that case, the content invalidate is unnecessary as there is no
content to invalidate, so just ignore the request.
Change-Id: I52471a1739443ba8f1e514a5908678552246d80b
