Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

android.googlesource.com

Post reply on HN
Print view View original

201–210 of 393 posts

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#201

Post by coldpie »

chronogram wrote: post #146
akersten wrote: post #18

This is great news. Hopefully it fixes a lot of the jank that I've always experienced with Android Bluetooth. I don't think I've ever had a smooth experience - even with a supposedly flagship device (Pixel 4a!) I've encountered all of the following problems: * Devices getting stuck at max volume (thankfully not headphones) * Devices getting stuck at really low volumes * Devices randomly switching between absolute vol…

All my Bluetooth woes from iPhone finally went away when I got a Pixel last year. The iPhone is still here and being used, but not for exercising due to the connectivity issues. I think it’s just Bluetooth itself being cursed.

> I think it’s just Bluetooth itself being cursed.

Hence my desire for a headphone jack.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#202

Post by blihp »

est31 wrote: post #83
rkangel wrote: post #50

Earlier quoted context omitted.

My guess would be that they can apply much more pressure to the Bluetooth chip vendor. The buying power that Apple has for designing in a particular chip is much bigger than any individual Android manufacturer (even Samsung). That gets them the leverage to get the chip vendor to do what they want.

> The buying power that Apple has for designing in a particular chip is much bigger than any individual Android manufacturer (even Samsung) Why does Samsung have smaller buying power than Apple? Doesn't Samsung sell more phones than them? Or is it because while Samsung sells more phones in total, Apple still has the most successful single models?

A typical manufacturer approach is to beat the hell out of your suppliers on price to make your margin which is likely most of what Samsung does with its buying power. Apple does that but is also willing to throw money at issues and go as far as financing facilities for vendors. Where most manufacturers don't care about the device they sold the second it's out of warranty[1], Apple takes a longer term view of the relationship. So Apple is far more likely to say 'we need this fixed and are willing to provide X million dollars and a team of our own engineers to solve the problem' while Samsung probably goes more like 'make cheaper and make it better... and make it cheaper!'

So the reason Samsung typically has less influence is that when all you do is crush your suppliers margins to make your own, said suppliers don't tend to make much of an investment in making things better since they are incentivized to just make them cheaper.

[1] in fairness, they can't afford to: while Apple has an ongoing revenue stream from its devices, most other manufacturers don't. It's Google/Facebook/etc who monetize the devices post-sale while for the original device manufacturer it's merely a liability at that point. This is a factor in why Android has a rather dismal track record re: updates on older devices.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#203

Post by acdha »

vardump wrote: post #187
seanalltogether wrote: post #28

Earlier quoted context omitted.

Any insight into why Apple seems to have a much better bluetooth stack? I do a lot of BLE development that has to work cross platform, and we see constant GATT connection issues on android compared to almost none on ios.

As a long time Apple user, I really don't know where that's coming from. Endless issues with bluetooth over the years, including full system crashes. Curiously iOS bluetooth stack seems to be more stable than on macOS. Or maybe it's just hardware differences. Apple's stack does work great with Apples hardware, though.

How many hardware devices are you talking about? That's very different than what I've seen personally or peripheral to enterprise support.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#204

Post by blep-arsh »

ArchOversight wrote: post #137
benbristow wrote: post #133

Earlier quoted context omitted.

I still find it buggy on my iPhone 12 Pro, as a user at least. Often says 'connected' to my headphones (Sony WH-100XM3's) when it's not, connecting to Alexa devices to stream audio often fails and requires a reboot to connect properly. I can't believe Bluetooth is still such a pain in the bum in 2021.

Buggy Bluetooth on the other end... Alexa is running Linux, and the Sony is probably some custom bluetooth stack. Once you move to all Apple bluetooth, things really smooth out. It seems that Apple does way more testing/validating of their Bluetooth stack.

They don't smooth out, for me, at least. Airpods Max, for example, can just decide to transmit nothing but deafening static to the other side in the conversation.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#206

Post by [deleted] »

qbasic_forever wrote: post #161
mondoshawan wrote: post #37

Earlier quoted context omitted.

On Glass, we actually went to Broadcom and had them on the ropes for fixing parts of their firmware. Sadly, we couldn't bring those fixes out of the closed source world of hardware, so it's still up to the system integrator to fight those battles...

Serious question, why doesn't Google build its own bluetooth & BLE chips? Please put some competition on Broadcoam and the like and either push them entirely out of the market (good riddance), or force them to step up their game.

[deleted]

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#207

Post by SketchySeaBeast »

izacus wrote: post #170
SketchySeaBeast wrote: post #34

Earlier quoted context omitted.

That's bizarre. I have a Samsung phone with Samsung Bluetooth earbuds and I've only ever experienced a single connection issue in the whole year I've owned them and they are a daily driver for me. I wonder what the difference is.

Samsung phones actually use their own Bluetooth stack not the one from AOSP Android. This is why the Bluetooth feature set sometimes doesn't match with the others.

Well that solves that. It seems much more reliable.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#208

Post by Abishek_Muthian »

parwan98 wrote: post #10
mondoshawan wrote: post #2

I know the guy that heads up the team that did this work -- he and I spent 2+ years fighting Broadcom's old, god-awful bluetooth code. Our whole team used to play what-if games about replacing the thing while massive code dumps came in from vendors, making the task ever larger. Zach, if you're reading this, HUGE kudos to holding the line in replacing that, and double kudos for doing it in a verifiable, sane language!

> fighting Broadcom's old, god-awful bluetooth code Correction: god-awful host side bluetooth code. There is still the bluetooth firmware residing on the BCMxxx chip (or Qualcomm chip) - >1MB of god-awfulerer closed-source code, half of it is in ROM (with limited number of available patch slots), full of bugs. You can see it crash from time to time in the kernel debug logs (and auto-restart itself)

Even if some courageous developer there fixes the bugs and updates the firmware; how many end-users would actually receive the update and actually apply the update? That's the problem Linux's LVFS[1] solves but it's unfortunate that not all manufacturers support it.

I got update for my half a decade old Logitech's 2.4 GHz receiver (nRF24L) for wireless keyboard as soon as I plugged it on Linux, I've used the same keyboard on Mac and the official Logitech software doesn't even detect the device properly let alone update the receiver's firmware(no issues using the device though).

[1] https://fwupd.org/

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#209

Post by moonbug »

mondoshawan wrote: post #81
looperhacks wrote: post #63

Earlier quoted context omitted.

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 c…

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

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#210

Post by coryrc »

yjftsjthsd-h wrote: post #147
ArchOversight wrote: post #137

Earlier quoted context omitted.

Buggy Bluetooth on the other end... Alexa is running Linux, and the Sony is probably some custom bluetooth stack. Once you move to all Apple bluetooth, things really smooth out. It seems that Apple does way more testing/validating of their Bluetooth stack.

I had the idea in my head (so take with a grain of salt) that parts of the BT stack are underspecified such that different implementations tend to have slightly different interpretations of the standard, so the problem isn't even which vendor you use so much as going all-in on any single vendor so the devices all agree on which reading to use. Although of course Apple might well be better anyways; one would hope that…

I've actually worked in this area. You are basically correct.

Sometimes you have to make a choice on which brands/chipsets you support. Devices on different ends of the compatibility spectrum can basically be mutually exclusive. IIRC if you advertise A2DP some devices supporting only HSP won't work, so you can make some hacky workaround but then your nicer A2DP equipment is harder to use. If you only need to guarantee support for X subset of devices you control, it's easy to tweak the settings so they work well together.

Post reply on HN