When the remote Jerry device is powered down the BT link to the
phone is dropped, and the Jerry firmware in the phone quite
immediately tries to re-connect to the Jerry device. Then
SDP and Discover Services is started, fetchRemoteUuids() ->
discoverServicesNative(). This results in an asynchronous dbus
call dbus_func_args_async() that is provided with a callback
function, onDiscoverServicesResult(), but before this callback
function is used Bluetooth is disabled according to the problem
scenario above. For some reason this discover services activity
is not cleared when Bluetooth is disabled, so when Bluetooth
is enabled again the (old) callback function
onDiscoverServicesResult() is executed, but the following
getAddressFromObjectPath() fails. The reason for this is that
the deviceObjectPath parameter contains an old value,
containg the process id of the old bluetoothd (the one running
before Bluetooth was disabled). Then the new updated
AdapterObjectPath /org/bluez/<new bluetooth hd pid>/hci0/dev_
is not a prefix of the old deviceObjectPath /org/bluez/<old
bluetooth hd pid>/hci0/dev_<BT_ADDR>, which results in that null
will be used as address in sendUuidIntent(), and later on,
ending up in the BluetoothDevice constructor where and
IllegalArgumentExceotion is thrown due to
Bluetooth address = null. Then the phone will crash.
Making sure sendUuidIntent() is not called when address is null
is a work-around for the problem.
Change-Id: I8ff60bad80de3b379cef0970402943dfa4de3cfd
Fix smoothScrollPositionFromTop scrolling too far on reverse scrolls
Fix an invalid touch mode when smoothScrollBy attempts to scroll off
the end of a list
* New uses-policies value
* Definitions for storage domain and encryption status
* API to get and set encryption status
* Intent to launch encryption changes
* Both new calls bottom out in the DPM service and are suitable for
a device that does not support encryption.
NOTE: Nobody should use ACTION_START_ENCRYPTION yet. It needs a receiver
to be built in Settings (different CL).
Change-Id: I2ae193bedbec59f6ba46c0ec7de12ecf321e5803
LayoutTransition works by animating layout-related properties
(left, right, top, and bottom). This works great when that animation
is the only thing affecting the layout of the UI. But if there are other things
happening in the application that cause layout to run on that
container or in its parent hierarchy, this can cause the layout properties
on its children to get mis-set during the middle of the transition.
This results in artifacts like animating objects jumping to locations where
they would be were there no animation running.
The fix is to supress layout requests on that container (and its children)
until the transition is complete (then issue a layout request on the container
to make sure that the container has the correct layout data)
Change-Id: I15bf0423a11409f854076f86099233db7fe4edc0
I think what was happening is that it was using a different layout but we were trying to reapply the
RemoveViews because of some bad boolean logic. This fixes that, and adds some better debugging that
might show us what else is happening.
Bug: 3298062
Change-Id: I0984f24cb2960166c79b9f2cc7c6a98bd75e17ba
Allocation limits relied on conditionally compiled code in the virtual
machine that was disabled in released versions of Android. As such,
these setter methods were glorified no-ops. Now that the feature has
been removed from the allocator this interface is thoroughly obsolete.
Change-Id: Id7f9de37ecfece4b909e35f110e118e131457133
