Comment by rektide | Hacker News Reader

Comment by rektide | Hacker News Reader

Why not BlueZ, that everyone else uses? Android feels like the land of Not Invented Here sometimes, to me. There might be good reasons, but often it feels like it's just Google trying to insure Android is as incompatible / different as possible from everything else that runs Linux.

It doesn't help that almost none of the ChromeOS / Android subsystems or tools have not made it to any mainstream / regular Linux. They remain Google-only products.

I wish this company doing so much Linux work would be part of some broader community. There's some reciprocal question, of how hard it would be, why haven't other people gone in & say picked out some of the, say, ChromeOS containerization tools: how much effort has the world made to use the offerings in these mono-repos? Community takes two. But it still feels incredibly weird, so against-the-grain to see such an active but non-participatory Linux user in the world.

Backkground chit-chat aside though, technically what (if anything) makes BlueZ unsuitable for Android? Why is Google on their fourth bluetooth stack (NewBlue, BlueDroid, the Fuchsia one, now this)?

GPL is the problem. Hardware vendors won't touch it with a 10k foot pole because of the requirement to redistribute patches.

There's a history of wanting BSD licenses at Android's inception. If the BSD distributions hadn't run into problems relating to legal battles at the time, Android would be built on Mach with a BSD userland rather than Linux. Additionally, there was more vendor support and drivers for the Linux kernel than Mach. Sadly, for the fledgeling enterprise that was Android, it was better to start from Linux, and use Apache/BSD style licensing and write their own userland.

Also many hardware vendors use their stack to differentiate themselves from other competitors as at the end they tend to 'do' the same things. That stack keeps at bay people just copying their design wholesale and then undercutting their margin and using their drivers. Then even if they are willing, they many times included some lib they bought from someone else. They may even have the full code to use and have changed it as needed. But that 3rd party is usually some consulting group and guess what one of the very few things they sell is. It is a huge mess.

> Sadly, for the fledgeling enterprise that was Android, it was better to start from Linux, and use Apache/BSD style licensing and write their own userland.

Curious about your take on this. Why do you think it would be better if Android were mach kernel + BSD userland akin to Mac/IOS instead of Linux?

> If the BSD distributions hadn't run into problems relating to legal battles at the time, Android would be built on Mach with a BSD userland rather than Linux.

What legal battles were there? Wikipedia puts Android being started in 2003 [0] and then only legal battle I recall with BSD having settled in 1994 [1].

[0] https://en.wikipedia.org/wiki/Android_version_history

[1] https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....

Android's development started long before Android became a company officially, and there was more fallout from those BSD lawsuits than what is officially reported in Wikipedia -- especially since the settlement agreement included that those that agreed must keep silent.

Android used BlueZ in the earlier versions, but they changed to bluedroid for reasons I don't know, but I believe it was (in part?) developed by broadcom and thus was probably better supported (licensing probably played a huge part, too, since bluedroid uses a more permissive license)

Part of the reason was that Broadcom could directly support the connectivity guys. We just didn't realize how awful it was, but given that the the Android team didn't have that big of a connectivity team at the time, it seemed like a good idea.

The Glass connectivity team (of which Zach and I were a part of) actually had a few more engineers than the main Android team did, and given that connectivity was absolutely critical for our device, we had the strength to stand up to this mess and plumb its depths, and Zach was a key driver in most of the rework. Lots of our changes made it into mainline, and when Glass ended, I left Google and Zach kept up the fight, moving closer to Android proper.

BlueZ, btw, has its own problems all throughout the stack, and unfortunately suffers from political issues w.r.t. the hardware vendors.

does this work relate in any way to the ChromeOs's recent, abortive, new Bluetooth stack?

I don't have the foggiest about the politician issues. I was shocked to hit up the bluez repo copyright in the README[1], from the beginning 2000, to 2001, then a Qualcomm email address for one Max Krasnyansky until 2003. Practically ancient history but still a very interesting detail to me that I would never have guessed

I really really really appreciate you writing in. It feels.lile there is so little to go on, so little available to understand the weird twists & turns of how the world, the software world especially, developed. A little bit of background & insight is so refreshing to hear. Thanks again!

[1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/READ...

I get what you're saying, but a project as big as Chrome OS isn't really suited for a lot of outside cooperation and communication. More often than not, you want to ship a feature as quickly as possible, ship it to canary, then dev, beta and stable at some point. Community run projects require a lot more back and forth and you give up some control over your schedule if you involve them, if you want your stuff to get merged.

Firecracker however is based on Chrome OS' container solution and lives on as an OSS project run by AWS.

Bluez these days is pretty tightly coupled to modern desktop linux. IIRC the only official way to talk to bluez is through dbus (there are still a couple legacy ways through shared libraries though). I don't think Android seriously uses dbus though so that would be a pretty big issue.

And as a person running the latest mainline kernel on their daily driver laptop--I would not want bluez running the wireless peripherals on my phone. I can barely keep a wireless keyboard attached and working on this thing... in 2021.

Reply on news.ycombinator.com