Add BluetoothAdapterStateMachine to maintain a inter state machine other than
the public BluetoothAdapter states. This is a improvement to BluetoothService
code. 2 internal state are added, LoadingFirmware and FirmwareLoaded to place
the Bluetooth module in a ready-to-switch-on state so that it can be quickly
switched on to have a better user experience
bug 5021787
Change-Id: Ia352e88cba509d9e98c900f85e7479f8cee1de5e
When the stack returns an incorrect error code, we were going on
in a loop trying auto pairing. Ideally, the stack shouldn't be returning
this incorrect code, but add a fail safe in the userspace code.
Also cap attempts at 2. There is no point trying more than that.
Change-Id: I5bf3ea871b9c2241ae5ac88e9818c9eb847fac92
Don't show incoming connection dialog when the device shows
the pairing dialog - this means that the device has already been
trusted by the user.
Change-Id: I98a9f56528f6b62d0f824bbc7612aaa0077ba1e6
Majority of the cars don't auto pair unlike headsets, as they have a display.
Instead of maintaining a blacklist of such cars, disable
auto pairing with 0000. This is legacy anyway as newer cars
come with 2.1 pairing.
Change-Id: I644e2da4d11cf2d250d846853523d7975ca000fc
Add the flag to Connection state changed intent because
external devices can get connected before booting is complete.
Change-Id: I5bed7a4aa75a42d6facc16aac4f2734e4b5fe246
1. Remove the check of configs in BluetoothHealth.
This check is useless since BluetoothHealth is a proxy.
2. Add a wrapper and a callback class. We shouldn't expose
Binder interfaces as public APIs.
Change-Id: If62620b4251cf93f3f97d2fe63099e40fae7da4d
This sends the intents to the Settings app to show
the dialogs for the incoming connection requests.
Includes down merged contributions from Jaikumar Ganesh.
Change-Id: Ic8b857aad3554315aae39a0e871eb94d0ac98a91
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
When there are no paired devices, pairing a new device
will cause a crash since the profile proxies will be null.
Change-Id: Ie1a9fd198e46d7e9cc2ba1b2f3a806b3c709f568
This first patch implements all the APIs.
The APIs wil be made public soon. The data specification
API will be submited in another patchset.
Change-Id: I2462683b7e07380e2c42474b0036b34d03b4bed1
We should never have to look on the entire instance. There
are many places in the code where it there and we need to fix it.
This is a start. In this particular case what we are protecting
is the properties map of the remote device and thus we just need to lock
on it. Ofcourse, it would be better to have a state machine but this
is good for now.
Deadlock: When a new device was found it will call addProperties which will hold
a lock. addProperties calls into BluetoothService. Now Settings app makes a call
into BluetoothService which will call into this file and we have a deadlock.
Change-Id: Ieb69d5ace222bf5d1e6677af151241153303099f
Move connect / disconnect / set and get priority
functions down the interface as they are not generic enough
for all profiles.
Change-Id: I2656e1bdbc8046c53bb0dfbd9172f5f10b57aa7d
The bonding failure status was dropped by function setBondState.
Fix the problem by passing funtion parameter reason to mBondState.setBondState.
Bug 3162947
Change-Id: I515af34dd04000dfc6ab44453594082136869460
During bonding bluez stack publish the error code over dbus.
JNI gets the error, in this ER case:
org.bluez.Error.AuthenticationFailed (Authentication Failed),
and then wrong call to overloaded setBondState() is made on
callstack using default result code parameter as 0 (BOND_SUCCESS).
Change-Id: I6f743cedc76e63d0c2a35e89d3aa48267b89c06e
Signed-off-by: Christian Bejram <christian.bejram@stericsson.com>
We used to do the priority change in the 2 services after the broadcasted
intent reach them. But that left a small time gap that could reject
incoming connection due to undefined priorities.
Bug 4096186
Change-Id: I9bb6aedc7ed98c53a9b00c48eedd20b0cf5f1660
Generates InetAddresses without risking an accidental dns lookup. For use with supposedly
numeric-only ip address strings.
Change-Id: I694f3976ce1c6382854706f6557ea88a289add3a
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
