 So, as I said, my name is Lukas and he is Shimong, we both work for Tieto and Tieto provides IT and software engineering services around the world. We both are really close to local connectivity area, working with Bluetooth, Wi-Fi and NFC. Daily, we work with our clients, supporting them in developing and maintaining local connectivity solutions, but we also do some kind of a side work, I mean, we try to explore new technologies and things, our company help us with doing this. So, Bluetooth Low Energy, what's that? This is, you can think about it like a completely new protocol stack, which is creating a new branch of use cases with peripheral devices, which gives you possibility to get a lot of different data, the devices having different sensors you can use in a fitness area, in a healthcare area, on home entertainment. Before it was area only for Ant Plus and ZigBree, but now Bluetooth goes into this area as well. So, as the name is Low Energy, so this solution provides, I mean, the main idea is that devices, the peripheral devices will be staying on the one cell battery quite long, like half a year, and that you can quite easily and fast connect to those devices, like comparing to the standard Bluetooth, the connection time is 6 milliseconds, comparing to 100 milliseconds. But with this also goes some limitations, there is lower throughput in the application layer, you can have like 300 kilobits per second, instead of 2 megabits per second. And also lower range, which is 15 meters instead of 100 meters, which you could have with standard Bluetooth. But yes, Bluetooth Low Energy was quite interested for us, mainly because almost all smartphones at the moment on the market has chips that are ready for Bluetooth Low Energy. But unfortunately there is a lack in between, I mean, there is host does not support it in Android devices. So basically, how it looks like, basically at the moment, there is no standard Google API for Bluetooth Low Energy. And if you are an application developer, you actually don't know how to start. There is a couple of solutions provided by different vendors. One of them is Broadcom, who provides API. And API is, you can access this on the website. When it comes to this API, it's a gas-based API, which means that if you want to write application above it, you need to have knowledge about Bluetooth, about how GAT works, how to play with characteristics. So you need to go through the specifications. It's not such easy that you just create an object which gives you some kind of data which you can show on the screen. And with this API also, this API works only with Broadcom Bluetooth stack. And of course not all devices have this. And also this API requires some framework changes which are not in every phone. I mean, even with Android 4.2, where the standard default Bluetooth stack is Broadcom at the moment. This distribution lacking in the framework changes, which allows you to use this Broadcom API. Other solution available on the market at the moment is Qualcomm solution. I mean, Kotal Aurora. Forum provides this code. And this is closer, I mean, it's closer to community because it uses Bluetooth stack. But this stack is highly modified. Also framework requires a lot of changes. I mean, Kotal Aurora Forum provides framework with a lot of changes. It means that if you want to have this, you want to have this solution, you need to rebuild all project to build, to, to, and to flash your phone. And also this, this API has a gut-based API and was really connected to Bluezy API. And also the same as with Broadcom, you need to have knowledge about how to play with characteristics and how to use it. And when it comes to 4.2 support, then it looks like, we look a bit into this code and it looks like the Broadcom BlueDroid solution, which is the default one for the 4.2, is now disabled and they just roll back to, to, to the 4.1. So it means that the whole framework part is the old one. The whole, the whole Bluetooth whole, which is, which comes with the 4.2 Android is reverted and the whole solution is used. And there's a Motorola API, which is, which is actually quite nice. I mean, it's a profile-based API. So that means that application developer doesn't really have to know a lot about the technology. You just need to create the object and get the data, callbacks with the data ready to show on the, on the screen. And as we, as we investigate this API, this, it is above the, this is above the code, which was developed by Qualcomm. So basically it was, it was like the, how to say this? I mean, basically it was the, the coder forum code has been used in for Motorola solution. So I would say that this Motorola API is above the Qualcomm solution and wrapping this and provides the, provides the, the higher API for developers. Yeah, the only problem is that, that Qualcomm solution is not fully ready. And this is what they also stayed on the website. And when we try that, we, we also noticed it, that there's quite a few issues when you try to connect, reconnect and et cetera. And of course for, for, for 4.2 Android does not, I, I, I don't think it's a good solution. So I want to tell you how, how we start with our heart rate profile for Android. I mean, one day we, we bought the Polar device. At that time it wasn't so easy to get such that what we managed to do it. We bought the Bluetooth 4.0 USB dongle. And we start playing with it on, on PC with a, with a Linux on it. So we use Bluezy. We found some different problems like, like there's some kind of issues when you fail to connect and the management, the management state was wrong in a kernel or I have, or for example the, that only one connection could, only one item to connect could be done during the, I mean, stack was in a bad state. I mean, like you could send couple connect request and stack get into bad states. And some other quite simple issues and yeah, we'll just fix it. We put the, we send the patches upstream and, and we get the idea. Why don't, why don't do it on Android? And yes, our company actually agree on it and we start looking more into do it. How to do it into Android? How, what kind of ideas, how, how it should work? So our idea, yeah, our, we had like three principle requirements which we put on ourselves. I mean, our code should be close to upstream. We didn't want to do more, a lot of changes to our speed. I mean, the goal was to not do, to do no changes for in our speed code. So you could take our solution and, and install it on your, on your device without rebuilding the whole system. And also isolate framework and application changes if possible. So to, to, to keep the upstream, to keep code, code close to upstream. We had to solve the problem with the kernel since kernel running on our device was 2.632, 32. And to have a support for Bluetooth low energy in the kernel, we had to use something newer. I think from, it's from, from starting from 3.5, the low energy is enabled in the kernel. You could use all the kernel, but you had to manually enable it, Bluetooth low energy. So, so we use compact drivers for it. We basically build a newer Bluetooth solution from the compact drivers. Then we get, then we have to thought about the bluesy, how to, which release to take. And on ICS, I mean, at the time we started, bluesy 5.0 wasn't available. I mean, even now it's, it's, I don't think it's in a good shape to, to take it. So we, what we did is, we did, we, we take all the changes from bluesy 4.101 before the API has changed. It's also easier for us to do it because we didn't want to change the existing Bluetooth path, like the Bluetooth, even loop, which, which handles all the communication between bluesy and the upper layers. So we want to keep it untouched. Yeah. So once we take this latest, yeah, latest bluesy, we also had to think about the Android specific code, which was always in a bluesy. And for this, we, we, we decided to create a special plugin which handles all the specific, specific tasks like aesthetic properties, the name, also getting RFCOM channel for the application. So it, it, we put it like, as a plugin, which keeps it nice in a stack. And the, the only thing we had to add at that time was we, we had to expose GAT connect and disconnect on D-Bus. It was in the break, because you have, here's written that for generic GAT API, but not only, if, when we use them, when we use the watchers, I mean, when you register on watchers for the specific profiles, low energy, low energy profiles, then, then we had to trigger connect to, to GAT anyway. So that's why we need it, but also we thought that it might be useful in the future when we want to expose also GAT API for the application if they would like to use it. And, and actually profile, we implemented it in Daemon and we upstream it after a couple of refactors. And, yeah, that would be it. So basically, this is how, how the solution looks like. I mean, you will use the compact drivers, which we built in the kernel. Then we did modification in Bluezy Daemon creating the heart rate plugin, heart rate profile. Then we, yeah, as I said, we want to keep it separate. And we didn't want to put any code here. So what we did, we create other second debas loop here. And this way goes all the, all the BLE communication. Then we create the helper components here, which register watchers for the plugins here, for the profiles here, and GAT device which wrap those things. And this GAT device was some kind of proxy application beans to it and get the profile once. So we provide two profiles at a time. This heart rate profile and second profile. So the application gets this profile and automatically get all the callbacks with, which provides the data, which are ready to show on the screen. So it is, yeah, so our idea actually has been fulfilled with this solution. And here comes demo. I don't want to show you how excited I am staying here. So I don't show you my real heart rate at the moment. But if you want to, if you want to take chance and check your heart rate, I can do it after this presentation. So we use the Nexus, Galaxy Nexus, and this polar device. You can see, yeah. And then Android.4.2 has come and everything has changed. Good things, and I think Simone will tell you more about it. Okay, so with Android 4.2, there was a big revolution regarding Bluetooth subsystem. Let me first describe what has changed. Basically, Google just ripped off all the bluesies tag and replaced it with Broadcom. Well, open-source solution from Broadcom. So the new stack is called BlueDroid. It's a totally different solution compared to bluesies tag. It doesn't use its debas, for example. It is not a system demon running on a device. It's a thread inside a virtual machine. But they make some of nice changes related to adding an abstraction layer for a Bluetooth stack running below. So VT-HAL API was introduced, which provides callbacks for basic Bluetooth stuff, like getting adapters properties, getting device properties, some pairing stuff, like confirming PASCII, entering PINs code, and so on and so on. What is different in this stack is it doesn't use a standard HCI interface, which is commonly used on Linux. And it doesn't use kernel subsystem, Bluetooth kernel subsystem. So this stack is totally a user space based. And at the beginning we thought, okay, maybe this stack has a nice low-energy implementation because Broadcom advertises that. But we did some investigation and unfortunately there was no low-energy API framework. So from an application point of view, it was basically the same as in previous releases. And we thought that maybe just configuration, as you say, because there were some configuration flags like EnableGuard, EnableSecureManager. But when we enabled those flags, basically, BluDroid stopped building. There were some missing files, missing headers, some functions were sweep of functionality. So it basically looks like Broadcom just removed low-energy support from stack before open sourcing it. And also the HAL API that was introduced doesn't contain any low-energy related functionality in it. So we decided what we can do about that. And we thought, let's try with BluZee one more time. So why we thought about that? First, it has full, pretty, well-working low-energy support in it, including number of profiles that we can have out of the box. It is community-driven, so we can influence the way it is developed, more or less. Like upstream new profiles, which we will have maintenance from community. And thanks to the BT-HAL introduction, we can try to minimize the impact of switching stack under the hood, at least for a framework part. And other things was that we could use some of our solutions from Ice Cream Sandwich and Jelly Bean 4.1. I mean the framework upper-liers like profile, IPI and so on. So there is some risk, unfortunately, related to that switch. Basically, we want to have no regression in functionality related to classic Bluetooth support. And I will talk about this risk a bit more, a bit later. One nice thing about BluZee 5 is that it doesn't require any configuration files anymore in ATC folder. So we can make it a configuration-based purely in runtime. So this is good because we don't need to put any extra files on file system. So the integration is even smoother. So how we try to approach the problem? Basically, we need to re-enable stuff that was disabled due to BluDroid integration. So we enable the HCI interface basically by restoring the HCI attached service that brought us standard kernel interface for user space. We follow the same approach as was described by Wukash for previous releases. So we use Compat drivers to get the latest and greatest Bluetooth subsystem for kernel because low-energy support is still being developed. New features are added, so we wanted to have the latest code. We need to re-enable the Deepass Demon. Fortunately, the code was not removed, so we just had to add it to init to start it and that was it. And next thing was bringing BluZee 5 back to Android. So what we decided was that we don't want to go with old BluZee legacy stuff like for API that was used in previous releases. Because we don't want Android modification that was done by Google for the fork of BluZee 4 branch. So basically, we took upstream version. At that time, it was 5.2 release. We added the make file and cross compile it and run it. So the state is now we have a running Deepass, running BluZee standard interface enabled so we can go into Apple layers. And so what we need to do, we need to have a BT-HAL implementation basically that hooks into a HAL and talks to BluZee through Deepass. So we prepared a sort of wrapper library, call it Tieto BT-HAL. And I will explain in a moment how it looks inside and why we choose that way. So a bit more details. Basically, we didn't want to make a mistake that Google did when they implemented support for BluZee 4. But we didn't want to have a hard-coded implementation of JNI framework that directly uses LibDbass to talk to BluZee. Because that was problematic when some API changes. If you want to extend that, you have to do a lot of coding with low-level library like LibDbass is. So we created an abstraction library. We call it BT-HAL of AbstractionLayer, which basically wraps the Deepass into a simple C API. So it hides all the implementation details like running EventLoop, having Deepass connected and so on. We used a really cool tool called GDBassCodeGain to generate those APIs. So we didn't have to write every single C wrapper for DeepassCode. So as much as possible the code is auto-generated during the build. We just provide some threads to run the loop and so on. And we also didn't want to make too much modifications for a BT-HAL API. I will explain later why. So basically we decided that we will try to extend the get-profile interface call from the BT-HAL so that we can expose extra profiles from low-energy like hardware or cycling speed or whatever. So I will now explain what are the risks of going with Bluesy. There is a problem that basically Bluesy 5 is one of components of whole network stack, let's say, from Intel. So when you want to go with Bluesy you have to probably take Ophono, Conman and other standard tools, let's say. And we didn't want to do that for Android. So there is a problem basically with A2DP support. Bluesy 5 is using DeepassMedia API which allows other process to handle multimedia processing over Bluetooth. So there is no ASA plug-in like it was in Bluesy 4 times when you just loaded the plug-in and it handles all for you. Basically in standard Linux this is handled by PulsAudio. We don't have PulsAudio here so our idea is to make a plug-in, an ASA plug-in that will have its own Deepass loop and will try to wrap the media API into a plug-in that can be used by AudioFlinger. But there was a presentation today about using PulsAudio on Android so maybe it will go that way. So if we would have a running PulsAudio in Android then we have a media API support for free because PulsAudio I think version 3 supports that out of the box. So that's one of the risks we need to still solve. The other one is headset and hands-free profile. That's a bit complicated because basically in Bluesy 4 times all the hands-free 80 command parsing was done in a plug-in inside Bluesy. Now Intel Guys decided that the right place to do 80 parsing is Ophono which is a modem demon that handles modems and so on, which is not that bad decision if you run Ophono on your system. So we still need to think how to solve it because normally BlueDroid does 80 parsing. So we have a missing block here. We will probably end up in reusing some code from Ophono as probably a plug-in inside Bluesy to handle that. And the other risk is that we don't know what Google do. I mean we don't know when and if they will provide a low energy solution in their stack. So we might end up in having some conflicts inside APIs and so on. That's the reason why we decided to reuse all the standard components. Because thanks to that we have our changes kind of nicely separated from Google code. So we don't mess up with framework, we don't mess up with BlueDroid itself. We basically just disable those parts of codes and use our own solutions. And this 4.2 low energy support is still working in progress so we don't have anything to show you how on a running device. We hope to have something ready for our next Bluetooth unplug first and I think it's in June. So maybe we will show there and try to do some IoT testing with running Jelly Bean and Bluesy stack. We'll see. And the main reason is that this is sort of a site project for us. It's some kind of research when we try to explore new possibilities with this low energy support. Maybe also with a few words. Why we decided to go with Bluesy in first place? Besides those points that were described before, implementing a stack inside Bluesy gives us support also on other Linux systems. Linux systems like standard distributions or Tizen for example or any other system that's using Bluesy. And this makes a bit less fragmentation in Linux world. So you have one implementation when you fix a bug in Bluesy running on Android, you have the bugs fixed on other systems as well. And that should improve the IoT a bit. And the last thing is that we want that solution to be easy to integrate into people's projects. So we want to have a very easy solution to enable low energy support in custom projects. So we try to wrap everything inside the build config flux. So what will let's say you have some product based on Android IOSP and you want to have a low energy support. So basically you will have to synchronize with repository. It's not available on the net yet. I don't know if it will be or not. And basically in your board config file you would have to define a new flag. It's now called board have Bluetooth Bluesy which will basically enable building Bluesy and the components and disable Bluetooth. Another change required will be init file modification because you have to run AC attach service, Deepus Demon and Bluesy Demon. And if you are using custom kernel you would have to integrate compact drivers. If not we basically have a make file that is using IOSP kernel without any modifications. Just attach compact drivers module and you have a running solution. So that's basically the main idea. What is done now is that we have Demon running. We have pretty much ready the proper library and working on BT-HAL. So in a month or two we should be ready to try to show some working solutions. And I think that's basically all we have to share to you. So if you have any questions or ideas or critics or whatever it's welcome.