Bluetooth plans

Registered by Sebastien Bacher

Ubuntu is currently using bluez 4, we should list our futur requirements and see what we will do with our bluetooth stack.

One first step could be to update to bluez 5, there are several API changes and that will require a transition.

Blueprint information

Not started
Sebastien Bacher
Needs approval
Mathieu Trudel-Lapierre
Series goal:
Accepted for saucy
Milestone target:

Related branches



Bluez 5 list of changes:

2013/03/01 chat

ELS goals are basic, but implementation isn’t complete with what we have today in Ubuntu (e.g. pairing isn’t complete)

Do we use the Android stack including Android kernel bits?

What’s the license of the android bluetooth stack?

Currently we have no working bluetooth on the devices we support because bluez is not compatible with the android kernel.
We either need:
- to figure if we can make bluez work on top of the android kernel
- move to the bluedroid stack instead of bluez

A2DP support? Not working well when multiple bluetooth connections are active, but might be related to specific devices

We need support from the kernel team

Is it hard to implement connection sharing with either stack? Bluedroid obviously has it; Bluez also would have it

Bluez 5 brings a load of changes (

Do we need to run certification for Bluetooth stack? => question for Pat and Victor

things we need to figure out:
- can bluez run on the android kernel?
- does bluez support all the feature we need?
- we will need to get the stack certified?
- why did google decided to change for bluedroid (it doesn’t use dbus, maybe the reason?)
- if we use bluedroid and it has no dbus, how do we talk to it?
- network-manager talks to bluez

what part of our stack use/speak to bluez?
- network-manager (talk to bluez currently)

libbluettooth3 rdepends: pulseaudio, network-manager, gnome-control-center, obexd, gvfs

we have a relatively recent indicator-bluetooth in GMenuModel; not sure about chewie though
we need to solve the question of the stack we are going to use before we can tackle the UI

topics of discussion:
settings UI
indicators UI
QA / testing
device support
power management

we need to figure out how we do testing

Needs test plan, manual testing of specific devices, automatic testing of some devices, automatic testing of use cases

APIs > not sure we need one for apps (will be some API to e.g. allow network stack to use the bluetooth stack)

Bluetooth connection sharing with iPad >> do we need to support? Doesn’t work with Android today

There aren’t any proprietary drivers that we know of, but there might be drivers behaving better against bluedroid than against bluez

Input needs to work with MIR

Do we want to spend any time upgrading from Bluez 4 to Bluez 5?

Actions / next steps:
trying bluedroid in Ubuntu Touch images; can we get it to work, how much is missing, what would it take to run it properly etc.? -- Mathieu
trying bluez in Ubuntu Touch images -- Mathieu
QA conversation on bluetooth -- Loic
followup meeting -- Seb
don’t upgrade from bluez4 to bluez5 yet -- Seb


2013/03/18 update

Review of actions
Mathieu tried putting Bluez back on 4.2 on the Touch images; is a bit painful -- adding Bluez, DBus and Glib in CyanogenMod
In container vs in Android? Would seem easier to get it working on Ubuntu image, but not sure; installing bluez in container but didn’t work too well -- didn’t detect any device
might be related to device handling bits in Android e.g. ueventd
Bluedroid not explored
would be a relatively large task to convert Ubuntu bluetooth apps to Bluedroid; would have to use libbluedroid -- no dbus interface
apparently relies on Java service talking to libbluedroid?
isn’t reusing hciattach etc.

Need further investigation on technical stacks.

Also need to build plans on bluetooth indicator and such.

Questions we’re trying to answer for the stack:
Will Bluez work in container?
NB: Michael is leading an effort to start in Ubuntu first and start udev rather than starting in Android first; this would make running Bluez easy
Which profiles are supported only in Bluedroid and not in Bluez that we really need in the ELS?

Bluedroid probably used because it avoids dependency on dbus and recursively on glib

added workitems

2013-07-19; mathieu-tl:
List of bluetooth profiles in BlueZ vs. Bluedroid from what I could find looking at the code:
Used for bluedroid;
and for BlueZ 4, BlueZ 5.


Work Items

Work items:
[cyphermox] Build list of Bluetooth profiles supported by Bluez vs. Bluedroid: DONE
[awe] Prioritize Bluetooth profiles from list and raise with product management: DONE
[cyphermox] Get Bluez running in Ubuntu Touch Ubuntu container: DONE
[cyphermox] Fix device-specific BT initialization code: DONE
[cyphermox] Fix device-specific BT initialization code on flipped image: DONE
[cyphermox] Investigate AOSP's BT power code and whether or not rfkill is used by AOSP: DONE
Implement Setup New Device wizard ( formerly part of gnome-bluetooth ): TODO
Implement Send/Browse Files application ( formerly part of gnome-bluetooth ): TODO
Investigate BT System Settings for Touch: TODO
Investigate BT audio for media playback on Touch: TODO
Investigate BT audio for telephony on Touch: TODO

Dependency tree

* Blueprints in grey have been implemented.