This takes care of the conditions where the bluez audio drivers
are not up and we try to make the call to connect the sink.
This would get rid of the hack in Settings app.
Use this in various places where it should serve no purpose to deliver
both broadcasts. This is intended to reduce somewhat the flurry of
broadcasts that we churn through during boot.
(CrashData was a custom-marshalled crash-info class used for a server crash
reporting system I am deprecating). Use ApplicationErrorReport.CrashInfo
instead to report crash details (mostly the stack trace) from RuntimeInfo to
ActivityManagerService, since we're likely to need the crash information in
that form anyway.
Remove the (long-disabled) flags and support for the "Debug" button
in the crash dialog.
Further gut the ICheckinService interface by removing the crash-reporting
APIs (and everything that calls them), plus the synchronous checkin()
method (which has been stubbed out for a while now).
A new dropbox-based crash reporting system is in the works, but not part
of this change.
Merge commit 'f6e32e72a902d9a309410bc5306a539ea850159f' into eclair-mr2
* commit 'f6e32e72a902d9a309410bc5306a539ea850159f':
Maintain a list of all Bluetooth docks.
With this change, isBluetoothDock API can be used anytime and is not in tied
to dock state. The Dock State is a sticky intent so users
can query for the dock state.
Dr No: Eastham
Bug: 2133530
Merge commit 'ae88e2d130a4d69bdf7ddc58f6ae512ea63087ff' into eclair-mr2
* commit 'ae88e2d130a4d69bdf7ddc58f6ae512ea63087ff':
Add API to get Active Sinks.
We need to expose SearchableInfo in the SDK in order to unbundle
Quick Search Box. Since the android.server.search package is
hidden, I'm moving SearchableInfo to android.app, where
SearchManager lives.
This change doesn't actually expose SearchableInfo. I'll do
that in a separate change to keep the change that
api-council needs to review small.
This is part of the fix for: http://b/issue?id=2270838
Change-Id: I9589f9c2c11d36c958beedff8245fe0c3319c6ba
1. PRIORITY_OFF is when user unchecks A2DP connection profile box.
2. By default, when you bond, it will be PRIORITY_ON.
3. When the profile gets connected, the priority gets set to
PRIORITY_AUTO_CONNECT. This means that we will connect
automatically to this profile.
4. When the user disconnects, we downgrade the priority to PRIORITY_ON,
which means we won't reconnect automatically.
a) We need to make a similar change to Handsfree profile.
b) We need to rework the profile management design and code which
will fix the 6 second timer that we have for A2DP reconnection.
Add AUTO_CONNECT priority for Headset profile.
Also, don't set priority to ON while disconnecting.
This logic has been pushed up to the Settings app.
Dr No: Eastham
Bug: 2133530
There is a delay between registering the two profiles,
and handsfree profile is a superset of the headset profile.
So some devices do an SDP and get the headset profile record
before we have registered the handsfree profile.
a) We can reject all incoming connections till all profiles are
registered, but then this would mean we connect later in some cases.
Registering profiles in this order seems fine to me.
Note: There is a also the need to fix forking sdptool to register
profiles, which would obliviate the need to wait 500 msecs between
profile registrations.
Bug: 2293792
Dr No: Eastham
There is a delay between registering the two profiles,
and handsfree profile is a superset of the headset profile.
So some devices do an SDP and get the headset profile record
before we have registered the handsfree profile.
a) We can reject all incoming connections till all profiles are
registered, but then this would mean we connect later in some cases.
Registering profiles in this order seems fine to me.
Note: There is a also the need to fix forking sdptool to register
profiles, which would obliviate the need to wait 500 msecs between
profile registrations.
1. PRIORITY_OFF is when user unchecks A2DP connection profile box.
2. By default, when you bond, it will be PRIORITY_ON.
3. When the profile gets connected, the priority gets set to
PRIORITY_AUTO_CONNECT. This means that we will connect
automatically to this profile.
4. When the user disconnects, we downgrade the priority to PRIORITY_ON,
which means we won't reconnect automatically.
a) We need to make a similar change to Handsfree profile.
b) We need to rework the profile management design and code which
will fix the 6 second timer that we have for A2DP reconnection.
Merge commit 'ad431ad8631d8b19b04193ff1f89a955a7643c60' into eclair-mr2
* commit 'ad431ad8631d8b19b04193ff1f89a955a7643c60':
Fix pairings lost on reboot.
Merge commit '660282dc3e81784224945be0787a9e2d4276de8c' into eclair-mr2
* commit '660282dc3e81784224945be0787a9e2d4276de8c':
Check if Bluetooth is enabled before making any calls down.
Merge commit '3c58d279abed1da56b0ece74ded5854c509a42a4' into eclair-mr2
* commit '3c58d279abed1da56b0ece74ded5854c509a42a4':
Fix BMW and Audi auto pairing lists.
Merge commit '013b0e531a4318b3e78c9bd0e077d3632fce2280' into eclair-mr2
* commit '013b0e531a4318b3e78c9bd0e077d3632fce2280':
Add BMW and Audi to Auto Pairing black list.
Merge commit '8de4e0ad8ff39d9a397cd80de5155d4c09ef98fd' into eclair-mr2
* commit '8de4e0ad8ff39d9a397cd80de5155d4c09ef98fd':
Add BMW kits made by Motorola PCS to autoblack list for Bluetooth.
Bluetooth A2DP suspend-resume improvements.
This change will reduce the occurence rate of A2DP sink suspend resume failures observed in issues 2184627, 2181005 and possibly 2189628.
More robust suspend/resume logic.
Use only the suspend request to audio hardware to avoid having two concurent suspend resume control paths.
This change will reduce the occurence rate of A2DP sink suspend resume failures observed in issues 2184627, 2181005 and possibly 2189628.
More robust suspend/resume logic.
Use only the suspend request to audio hardware to avoid having two concurent suspend resume control paths.
Merge commit 'd301c90446644f63cda9b9263f83332676065bb4' into eclair-mr2
* commit 'd301c90446644f63cda9b9263f83332676065bb4':
Delay 500ms between each registering each SDP record using sdptool.
This is to workaround an issue where SDP records will fail to register using
sdptool. When we run SystemService.start() it forks sdptool, so if we do this
four times in a row these forked processes can run in parallel, and one or
more of them fails. There is probably some thready safety issue in sdptool
or Bluez that makes it unsafe to run sdptool in parallel.
As a workaround, delay 500ms between each run of sdptool to register SDP
records when starting Bluetooth.
Before this fix it was easy to reproduce problems with service record
registration. If you turn BT off/on multiple times you can see that sometimes
one or more service records are missing. Repro rate is about 20% in my tests.
Result is that remote devices cannot connect to the missing service.
After this fix I am unable to reproduce any missing SDP records, after 30+
cycles of BT on/off. Motorola BT team also ran stress tests overnight with this
fix and were unable to reproduce the missing SDP records.
This is a low risk fix. It does delay some records from being registered
by an additional 1.5 seconds (on top of the 3 second delay we already had),
so if you try and very quickly connect a BT service after turning BT on it
won't work the first time.
Do not merge. (I will use a less hacky fix for MR2/Master)
Change-Id: I305c181c3194e8ce25e3825320cc2e1ef6d3d3cc
Bug: 2180800
DrNo: eastham
Joke: Why can't you play cards in the jungle? Because there's too many cheetas!
Make functions that are meant to be BLUETOOTH_ADMIN really
BLUETOOTH_ADMIN.
Add some missing javadoc for permissions.
The only functional change here is the BLUETOOTH->BLUETOOTH_ADMIN
changes. This is super safe because every system app that uses BT
has both permissions.
Change-Id: Iddc61f9fd5d81fe0171358665a0fa52f2fa02871
DrNo: eastham
Joke: How do you catch a rabbit? Hide behind a tree and make carrott noises.
Added a workarouond to request the A2DP output standby directly to audio hardware when the sink is suspended as it seems that the suspend request often fails.
Also take into account resume requests received while a suspend request is pending.
Sometimes during OPP, we can get stuck in Pairing state when the remote
end, cancels the Pairing process - we will just get onAgentCancel
and thus not set the Pairing state properly.
DrNo: Eastham
Bug:2174874
This is the main entry point to the Bluetooth APIs, and returns the default
local Bluetooth adapter.
It replaces context.getSystemService(Context.BLUETOOTH_SERVICE). This was
never in a public SDK release.
DrNo: eastham
Bug: 2158765
Joke: Why can't you play cards in the jungle? Because there's too many cheetas!
Change-Id: Ieed8be009ee5aba621cb69090ee8c8a9c19c840d
Hide createRfcommSocket(int channel)
Add createRfcommSocketWithServiceRecord(UUID uuid)
Rename listenUsingRfcomm(String,UUID) -> listenUsingRfcommWithServiceRecord(..)
Now we have a complete API for developers to make peer-peer RFCOMM connections
with hard-coding the limited (30) RFCOMM channels, instead using SDP lookup
of an UUID.
This commit addresses two serious bugs:
- Do not throw IOException on accepting an incoming RFCOMM connection with
BluetoothSocket. This was a regression from commit 24bb9b8af4
- Workaround failure of bluez to update SDP cache when channel changes by
trying to use the same RFCOMM channel on the server every time, instead
of picking server channels randomly. This is a pretty ugly workaround,
and we are still trying to fix the caching issue - but with this
workaround we are at least shippable and apps will work at least until
they start colliding on the 30 RFCOMM channels.
DrNo: eastham
Bug: 2158900
Joke: What did the digital watch say to his mom? "Look mom no hands."
Change-Id: Ia4879943b83afac06b6f1a3f2391cf1628afce7d
Hide listenUsingRfcommOn(int channel)
Add listenUsingRfcomm(String name, ParcelUuid uuid)
The new API automatically finds a free RFCOMM channel and registers an SDP
record with the given uuid and name. The SDP record is automatically
removed when the socket is closed, or if the application dies.
Apps are prevented from registering SDP records with the uuid of system
Bluetooth profiles, such as A2DP, HFP and OPP.
Apps are prevented from removing SDP records that they did not create. This is
tracked by pid.
TODO: Provide an API for the connecting app to look up an SDP record.
Bug: 2158900
DrNo: eastham
Joke: "What did the dog say to the tree? bark."
Change-Id: Ia92f51c34615a7270a403255ad2b8faa98c4a3f5
API council says:
"In reviewing the new triggerSearch API, we are concerned that
applications could use the option to perform a global search to spam
the user with frequent searches. We would like the global search
option to be removed for now (not just hidden, but removed from the
internal IPC API so that nobody can find this and abuse it). The rest
of the API should be fine as long as it is restricted to local
searches."
Fixes http://b/editIssue?id=2158785
Change-Id: Ie69a9c0ab6373cc4427aab50606885bdede40585
When turning off BT while connected to an A2DP/HFP headset we can hit the path
BluetoothHeadsetService.onReceive(BluetoothHeadset.STATE_CHANGED) ->
BluetoothHandsfree.audioOff() ->
BluetoothA2dp.resumeSink() ->
which causes resumeSink() to NPE because mAudioDevices.get() returns null.
It's a race between A2DP marking the device as disconnected, and HFP marking
the device as disconnected.
Fix is to NPE check in resumeSink().
Change-Id: I2782ac8c70ea1678d7de5fcd49bff8e03df36f4e
Sometimes we might be paired but the other end might not have stored the link
key. So when we initiate connection the other end will ask for the authorization.
This was setting out Bond State to Bonding.
Change-Id: Iba6fd660ac90a3f48da62e7b6cf479054624a5af
Instead add ACTION_REQUEST_DISCOVERABLE for the system to show a dialog to
adjust discoverable mode.
Also remove createBond(), removeBond() and cancelBondProcess(). The Settings
App already handles these automatically when connections require bonding.
Change-Id: I216154cd1b6de410de64ba91b07d7263ac03e8df
