This will allow us to recover if we crash while changing USB configurations
Change-Id: I22ba9a1ff0a8bcbfd4a0f18af0c95a3b66b99060
Signed-off-by: Mike Lockwood <lockwood@android.com>
We now have different strings depending on the current USB mode.
Change-Id: Icc6392d5700a6fee008b75287d8eb0f06db1d880
Signed-off-by: Mike Lockwood <lockwood@android.com>
Moved constants/methods specific to Voicemails and Status table under
respective classes.
Marked currently used constants as deprecated, which will be deleted
once the apps using it is modified.
Change-Id: I122439c32ac62e9ae83c4c8468f5160a79743335
A cell's ability to shrink or stretch is now integrated with the
constraints system, which is now supplied with both upper and lower
bounds.
Also:
. Remove package private access (pseudo) annotation
. Remove rowWeight and columnWeight attributes and fields
. Remove code to handle weights
Change-Id: I9e2432101d15466c621f51ae362435051fab5764
We must not call WebView.destroy() until after the WebView has been
removed from the view hierarchy.
Bug: 4974517
Change-Id: I33b3a9d4ec098e2ab50626cb8906da7697ff2a33
This fixes a problem where touches can get stuck because the
driver and the framework have different ideas of what the
initial slot index is. The framework assumed it was slot 0
but it could in principle be any slot, such as slot 1. When
that happened, the framework would start tracking the first
touch as slot 0, but it might never receive an "up" for that slot.
Change-Id: Idaffc4534b275d66b9d4360987b28dc2d0f63218
- Use PendingIntent to start activities.
- Handle configs without package names.
- Switch to system UID.
Change-Id: Ia78112a97e3628b603d9e059705e32694ebe142b
Under some circumstances, the broadcast intent
BluetoothA2dp.ACTION_CONNECTION_STATE_CHANGED can be sent before
the system is ready, triggering an IllegalStateException,
"Cannot broadcast before boot completed" and runtime crash.
Fixed the race condition by adding the
Intent.FLAG_RECEIVER_REGISTERED_ONLY_BEFORE_BOOT flag
to the broadcast intent. All system receivers of this intent
are registered with registerReceiver() rather than as components in
the manifest, so nothing should change in the event that the A2DP
connection state change is broadcast before boot completion.
Any apps that define a receiver for either
BluetoothA2dp.ACTION_CONNECTION_STATE_CHANGED or
BluetoothA2dp.ACTION_PLAYING_STATE_CHANGED in their manifest
will not receive these broadcasts in the case where they are sent
before the system has finished booting. Normally, user applications
should not care about these events anyway and should let the audio
manager take care of audio routing on their behalf.
In the event that an app does care about A2DP state changes, it
should either register for these intents with registerReceiver(),
or it can add an intent filter for ACTION_BOOT_COMPLETED and
test the state of Bluetooth and A2DP at that time. Apps which
care about the state of the Bluetooth adapter should do this also,
because BluetoothAdapter.ACTION_STATE_CHANGED is already being sent
with FLAG_RECEIVER_REGISTERED_ONLY_BEFORE_BOOT.
Bug: 4982088
Change-Id: I10e55713f9d07d6dc88b4480b45b1aeb3aaf170b