The package manager now keeps track of whether an application is
stopped. There are new intent flags to control whether intent
filters in a stopped application will match the intent. This is
currently used in one place, sending broadcasts, so that stopped
apps can not be launched due to background processes.
The package manager during first init makes sure no applications
are in the stopped state. When new applications are installed,
that begin in the stopped state. When the activity manager is
launching a component of an application, it ensures the application
is taken out of the stopped state.
The "force stop" button in manage applications will now put an
application back in to the stopped state; it can't go back out
of the stopped state until one of its components is launched by
the activity manager.
There will probably be a few more places where we need to filter
stopped applications out of intent matches, but doing this for
broadcast is a very big first step.
This also introduces a new broadcast that is sent to an application
after it is replaced with a new .apk. But only if the app is not
in the stopped state. This makes it a lot easier for developers to
implement code to get their application back in proper running shape
after an upgrade.
Finally another new broadcast is added that is sent to a package's
installer at the first time it is launched. This allows the installer
to tell the package about it being installed only when it is first
actually used.
Change-Id: I589c53ff0e0ece868fe734ace4439c0d202dca2d
a) Device is trusted.
b) Device is unpaired.
c) We need to set the trusted value before unpairing.
Else on the next pairing, the device will be trusted automatically
and we will not show the PBAP authentication dialog.
Change-Id: I8d7c962688885885d37be341e5494069294eb392
Several cleanups to BluetoothService:
- Move BluetoothService.BondState inner class to top level.
- Extract adapter and remote device properties cache management
logic into two new classes: BluetoothAdapterProperties and
BluetoothDeviceProperties.
- Add getter methods for other classes in the package to access
the new properties cache objects for multi-part operations.
- Inline log() method in BluetoothService and selected the
appropriate Log method (Log.d, Log.w, Log.e) for each message.
- Refactor dump() method into smaller sized pieces.
- Clean up logic of updateCountersAndCheckForConnectionStateChange()
method for better readability.
- Change sendConnectionStateChange() to return instead of sending
an intent if the current or previous state values are invalid.
Previously the code sent an intent with -1 for the invalid state.
- Added Javadoc comments to document the methods that are called from
native Bluez code.
- Fixed some typos and code style issues.
Original Change by: Jake Hamby
Modified by: Jaikumar Ganesh
Change-Id: I76ebac00ecd29566dcb2d1ad3e7a486b7530ce24
When we have a lot of devices paired and try to enable bluetooth,
loadBondState will take a some time. During this all UUIDs would
have been registered and we would send out the Bluetooth On intent.
When Settings apps or phone app gets the Bluetooth On intent, they
try to initialize state. However, the enable Thread in Bluetooth Service
is still initializing internal state in loadBondState leading to
ANRs and deadlocks. So register SDP records as the last step of enable Thread.
Change-Id: Iaa0a773e31b9d269f4c56c4f975a0e2973e02d6e
Distinguish between NAP and PANU disconnect in BT tethering
and call appropriate functions. We were never disconnecting
NAP role devices.
ToDo: BluetoothService needs to be refactored, its become too big
1) BluetoothAdapter and BluetoothDevice properties need to be moved to separate
classes.
2) BluetoothPanProfile and BluetoothInputDeviceProfile which are handled
by BluetoothService need to be moved to a separate file.
3) Integrate PAN to the profile state machine.
Change-Id: I32a8d274f38c78931434bd9738c8f6570ba89fcf
Wait till all SDP records are registered, before sending STATE_ON intent.
This would fix crashes in Settings app when the profile manager
is not registered.
Problem:
We were sending Bluetooth State on intent before we got the uuid state
change intent from Bluez, which is asynchronous.
Hence when the Settings app queries for the profiles
to decide if headset profile was registered it would get false and
the profile manager would be null causing crashes.
This was not 100 % reproducible, well because it was a race condition.
Change-Id: I791eb63dfbc78aba4c06fd8db933069cb5fde00d
PBAP is contact transfer to cars and headsets.
This is closely tied to handsfree profile.
Without calling functionality it was of practically no use.
It will just confuse users when they see a "Dial" button
on their car systems.
Bug: 3395362
Change-Id: I4e4597f0e4b371f69ed7af95d73893554e3fb8ac
Multiple HID devices can be connected. There is no pointing
maintaining the global state. Check individual device state.
Bug: 3350904
Change-Id: I03d9a6015e39e4f9d7f68cc8bbdb19731129b4e6
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
Try auto pairing with such keyboards.
Also fix bug where dynamic auto pairing file was not being created.
Change-Id: I93afb96fee8bc4f245f96ec5961979c620de7948
BT can come up before the system boots up and we send a broadcast,
this can cause issues.
Bug: 3259948
Change-Id: I53ce6b9851fbf611309db1f0a16768ef9f388e0c
InterfaceConfiguration changed to use InetAddress and stop with the string->int->string
conversions.
bug:2542681
Change-Id: I11c4954547333c43bb840fa0469ddde57b0d043b
SDP records are now registered with a dbus call so we don't have to wait
for initiating auto connections.
Also reduce time to connect other profiles case by 2 secs.
Change-Id: I8f0eab6a95d3bfaf11a8eb7495a024949639d7fc
1. These involve disk operations and multiple processes.
2. onPropertyChange already informs us asychronously.
3. Settings app is the only user, will have to revisit the function
if we make them public.
Change-Id: If019a83c05a0c9e625f27faf99063d33f369f0d8
Most of the time it will either be empty or have 1 device.
Using list makes it much a better API and since its supported
by the AIDL format, the code becomes much nicer.
Change-Id: I5a2508b33ba754fc8cc738409d658e1235aaf2cf
