Live data from Hacker News

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

android.googlesource.com

41–50 of 393 posts

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

#41
post #23

Since Android is Linux, will this become available to all Linux users?

You have bit confusion here. Android is based on Linux kernel, and changes on that is directly reflected to both Linux and Android users, it does not go to other direction. We will see if this code ends up on other use as well.

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

#42

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.

Could it be because they only have a handful of hardware variants to support, vs hundreds on Android? Presumably, the stack itself is somewhat sane on both sides, but the hardware's bugs, poorly specified or undefined behavior is constantly throwing wrenches in the machinery - Apple managed to fix most of them for the hardware they support, but Android has no chance as they have to support hundreds of different chips…

Possibly, but half the guys on the dev/qa team have google pixel devices and even they throw connection errors fairly regularly.

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

#43

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!

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.

Whilst they also use a lot of Broadcom silicon, the stack they use is written 100% in house.

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

#45
post #19

Wait , so can rust generally be replace C++ code in most projects ? Has anyone here had success with a partial to Rust migration.

It is very hard to answer such a general question with a definitive answer, but Rust does want to be viable for the same sorts of things in which C++ is viable. As always, your mileage may vary.

So to clear I can't just plop a Rust class into a C++ project.

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

#46

If you go into the parent directory, what appears to be the main Gabeldorsh directory, most of the implementation appears to be written in C++. Is the project being slowly rewritten in Rust? Or are only parts of it written in Rust?

The parent directory is the Android supporting stuff like the bluetooth HAL and the JNI interfaces. The rest is the old bluedroid/floride stuff.

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

#47
post #19

Wait , so can rust generally be replace C++ code in most projects ? Has anyone here had success with a partial to Rust migration.

I mean, Mozilla migrated parts of Firefox to Rust, that's the big one. I hear it might start being included in the Linux Kernel soon.

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

#48
post #20

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

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.

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

#49
post #45

Earlier quoted context omitted.

It is very hard to answer such a general question with a definitive answer, but Rust does want to be viable for the same sorts of things in which C++ is viable. As always, your mileage may vary.

So to clear I can't just plop a Rust class into a C++ project.

Rust does not have classes, strictly speaking, though you can define methods on structs.

https://crates.io/crates/cxx is the simplest way to do an integration. It is slightly more work than "just plop in" but it's not incredibly difficult. It's harder than mixing C and C++ together, but then again, almost no pairings of languages are that easy.

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

#50

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!

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.

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.
Post reply on HN