Live data from Hacker News

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

android.googlesource.com

331–340 of 393 posts

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

#331

The Android IPC driver (binder) is also being re-written in rust. It takes advantage of the upcoming kernel driver rust support in Linux. It is an obvious choice for a memory safe re-write since all android processes (including sandboxed ones) have access to binder

Hello,

I'm actually one of the main binder userspace maintainers in my day job there (opinions are my own), and I haven't heard about this. Do you have a reference? What has happened is that there is a userspace shim over libbinder called libbinder_rs which provides Rust support for binder, but AFAIK, the kernel driver and main userspace lib is remaining in C++. Still, would be cool.

Your Friend, Steven Moreland

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

#332
post #285

Earlier quoted context omitted.

> Prior to Android, all we had were closed source low powered feature phones and Blackberries. Symbian was open source, ran on millions of smartphones - most of which had app stores and web browsers. Some of which had touchscreens, GPS, augmented reality features etc. Don't get me wrong - Android has been brilliant. But let's not completely rewrite history, eh?

Right. I didn't think I was trying to rewrite history -- I'm simply pointing out a gap in the market that Android was attempting to fill. Asking me to enumerate everything out there at the time is silly -- especially given the haze of memory. Symbian was far more popular in Europe than it ever was Stateside, so bear that in mind. I had to import my Nokia E70 gullwing phone before I received my sooner, and what functi…

The browser in S60 phones was actually WebKit. In fact it was Nokia that started the work of fitting WebKit into memory-constrained devices.

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

#333

Earlier quoted context omitted.

I can't speak to this directly because of numerous reasons, chiefly among them being that I don't get to make those decisions. Standard disclaimer follows: I rejoined in the last two years, what follows are my opinions, these opinions are my own, blah blah. Android has never been about driving the hardware narrative -- it's always been about building a phone with mostly open contributions and driving the start of a w…

What a hopelessly naive perspective. Android has always been about ensuring the Google surveillance operation doesn't get shut out of mobile. The whole OS is designed to enable snooping on the user not just while in the browser, but at all times. The fact that they've had to build actual hardware that functions at times, and includes things like driver stacks is purely incidental to the main mission. Try seeing how w…

> What a hopelessly naive perspective.

Maybe, but I was there, helping it develop in the early days, which is the time span we're talking about. I can tell you the core of the Android team was fighting to keep it open -- so much so that about three years in one of the guys who dedicated his job to open sourcing drivers and kernel patches burnt out because of it.

What Android is about is decidedly not what Play Services and GCM core are about.

> Try seeing how willing they are to add support for chipsets on phones that don't include Google Services

It's always been the system integrator's job to work with the OEM vendors to integrate drivers and functionality into Android -- not the Android team's. Even on Glass we had to do this as though we were outside system integrators.

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

#334

Earlier quoted context omitted.

I can't speak to this directly because of numerous reasons, chiefly among them being that I don't get to make those decisions. Standard disclaimer follows: I rejoined in the last two years, what follows are my opinions, these opinions are my own, blah blah. Android has never been about driving the hardware narrative -- it's always been about building a phone with mostly open contributions and driving the start of a w…

> Android has never been about driving the hardware narrative Apple has been building its own hardware from the beginning, but still also uses Broadcom chips.

They have been integrating hardware from the beginning, not making it all themselves. What they do, though, is demand the ability to vet and fix vendor firmware.

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

#335

Earlier quoted context omitted.

Right. I didn't think I was trying to rewrite history -- I'm simply pointing out a gap in the market that Android was attempting to fill. Asking me to enumerate everything out there at the time is silly -- especially given the haze of memory. Symbian was far more popular in Europe than it ever was Stateside, so bear that in mind. I had to import my Nokia E70 gullwing phone before I received my sooner, and what functi…

The browser in S60 phones was actually WebKit. In fact it was Nokia that started the work of fitting WebKit into memory-constrained devices.

Oh, neat! I had no idea it was WebKit on there. Still, what I had wasn't exactly what you'd be comfortable using for more than a few moments. I bought one of the original Nokia Internet Tablets and put together a full wearable system back then to make things a bit better for myself, but I never used the browser in S60 for anything serious because it was so cut down.

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

#336
post #108

Earlier quoted context omitted.

The third half is the bluetooth firmware on the other device. The fourth half is the other firmwares on the other device. The fifth half is the specification(s). The sixth half is the RF environment.

But those are the same for iOS, yet Bluetooth on iOS is far better than on Android.

A huge factor is that iPhone has a large, long-standing market share, with relatively few different OS and hardware versions. This means that everyone else has been able to test their Bluetooth implementations for interoperability with iPhones.

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

#337

Earlier quoted context omitted.

Yeah from the Android platform side it would be weird to build chips. For products like the Pixel phone though, that would be a great place to innovate. And realistically, Google needs to get into the custom chip game sooner rather than later... GCE needs to start competing with Amazon's Graviton ARM processors. The sooner you get the expertise and talent to churn out chips (and maybe even a fab or two?), the better.…

Aren’t they already with TPUs?

Yes. And several generations in.

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

#338

Gah. Just two days ago I finished what must have been our fourth rewrite of Kotlin code to interface with Android BLE. It's a complete trial by fire experience. Various medium and other blogs on the net are a morass of "find the true information amongst the disinformation". If I had a nickel for every "just put a delay here" so called solutions. We have two apps, one that communicates over many variously configured c…

I went through the same thing recently. The best reference I've ever seen on Android Bluetooth is this series of posts:

https://medium.com/@martijn.van.welie/making-android-ble-wor...

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

#339

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…

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 bluetooth is different from Android, and it has been much better for many years now. In fact I use Galaxy Buds with my S10 and it is an amazing seamless experience. No lag, no disconnections, great audio quality, and I don't even need to have bluetooth enabled for them to connect, just need to open the buds' case. I don't know how that last part works.

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

#340

Earlier quoted context omitted.

Yeah from the Android platform side it would be weird to build chips. For products like the Pixel phone though, that would be a great place to innovate. And realistically, Google needs to get into the custom chip game sooner rather than later... GCE needs to start competing with Amazon's Graviton ARM processors. The sooner you get the expertise and talent to churn out chips (and maybe even a fab or two?), the better.…

Aren’t they already with TPUs?

Huge difference between designing for their own data centers vs consumer chips.
Post reply on HN