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

361–370 of 393 posts

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

#361

Post by jasonvorhe »

rektide wrote: 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…

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.

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

#362

Post by jasonvorhe »

vlovich123 wrote: post #329
qbasic_forever wrote: post #199

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

Google doesn't have the volume on its first-party hardware to drive something like this yet & they would never start with BLE chips. Additionally, there's some really good vendors out of China already challenging BCOM & QCOM FWIW, which further complicates the "build it yourself" narrative (look at the Pixel buds which have an AirPods-like experience running a Chinese BLE chip for the buds which other Western vendors…

Are you talking about the 1st or 2nd Gen Buds? Because the 2nd gens seem to have severe connection issues:

a) they frequently flip flop between at least two BT profiles, leading to a lackluster listening experience b) they lose connection to each other (leading to intermittend profile switches during reconnects, possibly due to lack of available bandwidth) c) they have severe signal quality issues, leading to limited range and audio interruptions

All these issues only happen with the 2nd Gen Pixel Buds, but not with a random sample of various other true wireless earbuds (I tested Sony WF-1000XM3, 1More True Wireless ANC, Airpods Pro) leading me to believe that this must be a hardware issue on Google's side, especially because the amount of people with the same issues is pretty high.

No other pair of true wireless earbuds hat any issues with music playback while I'm on a road bike, with my phone being on my back, only the Pixel Buds do - and I'm on my 2nd replacement already.

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

#363

Post by iopq »

oriolid wrote: post #162
shadowgovt wrote: post #119

Earlier quoted context omitted.

This, but slightly revised: it's because Samsung is in the market of selling cheap hardware. Apple sells luxury products and part of their value-add is leverage with their vendors. Apple can come to a vendor and say "these are our constraints on what we are willing to buy . Here's testing benchmarks. You are required to meet them. Failure to do so voids the purchase contract." The vendor will then, of course, say "We…

> Samsung is in the market of selling cheap hardware I'm not sure about this. There are people who pay >1000€ for their flagship phones and believe them to be premium products, but they are just as buggy as the cheap ones. Huge amount of CPU power and impressive camera specs, though.

I've never had one, can you expound more on this topic?

The S21 Ultra seems like a very good purchase from reviews. QHD screen with dynamically adjusted 120Hz seems really like the best spec.

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

#364

Post by eecc »

azernik wrote: post #307
eecc wrote: post #274

Earlier quoted context omitted.

Well, if the implementations of the standard are such a garbage fire what's the point chasing them? Just to check the box "standards compliant" and likely providing an abysmal UX and poor interoperability? I fixated on Apple because they're often picked on for taking the highway, but on the other hand what's the point doing otherwise? What's a common ground if it's just a pipe dream?

Just because a chip is shitty doesn't mean it's worthless. In practice, Bluetooth is quite interoperable, and reliable enough for many use cases (especially the common, better-tested ones). Breaking compatibility with that ecosystem out of spite is not conducive to getting adoption for a better product.

Well, the original posts report some frankly tragic scenarios - so bad that they “reboot to initialize” just to keep sane - in what are some pretty ubiquitous devices. Or not?

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

#365

Post by lifty »

bww wrote: post #196
glennpratt wrote: post #67

Earlier quoted context omitted.

Anecdotal, but my new 16 inch MBP drops BT connections all the time. I had to give up the keyboard and mouse I've used for years across at least 5 computers, mostly Mac's because they disconnected so much. Even the Apple keyboard and mouse I switched to drop occasionally.

FWIW, I also have a 16" MBP and I've also had a ton of problems with Bluetooth on this thing. I've noticed that Bluetooth connectivity is significantly worse when the laptop is closed. You might see if keeping it open helps. Resetting the Bluetooth module also helped resolve some persistent connectivity problems I was having (shift+option+click on the Bluetooth menubar item; choose "reset" from the menu). Eventually…

Wow, never knew about that combination of keys and the fact that it brings extended options in the drop down menu. Thank you!

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

#366

Post by asddubs »

mondoshawan wrote: post #333
KingHenryVIII wrote: post #313

Earlier quoted context omitted.

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

too bad more and more of android was moved into play services over time

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

#367

Post by jabedude »

xleviator wrote: post #331
jabedude wrote: post #13

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

Hi! Not a Google employee, but I'm volunteering on the Rust-for-Linux project which is bringing Rust bindings to the upstream linux kernel. A Google engineer is working on porting binder to Rust and is contributing as he implements it. See his comments here[0] and here[1].

[0] https://github.com/Rust-for-Linux/linux/pull/145 [1] https://github.com/Rust-for-Linux/linux/pull/130

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

#368

Post by bestorworse »

xleviator wrote: post #331
jabedude wrote: post #13

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

Thanks! I searched for this rewritten version and couldn't find anything.

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

#369

Post by bestorworse »

jabedude wrote: post #367
xleviator wrote: post #331

Earlier quoted context omitted.

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

Hi! Not a Google employee, but I'm volunteering on the Rust-for-Linux project which is bringing Rust bindings to the upstream linux kernel. A Google engineer is working on porting binder to Rust and is contributing as he implements it. See his comments here[0] and here[1]. [0] https://github.com/Rust-for-Linux/linux/pull/145 [1] https://github.com/Rust-for-Linux/linux/pull/130

Outch! Thanks for the refs.

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

#370

Post by mondoshawan »

asddubs wrote: post #366
mondoshawan wrote: post #333

Earlier quoted context omitted.

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

too bad more and more of android was moved into play services over time

It wasn't. Play services is just add on features that proxy app permissions and centralize push notifications -- no actual Android features moved into Play services that I know of. Ie: auto filling SMS OTP codes. It feels like Android is being sucked up that way, but that's because there are a lot of really nice features in there, like push notifications, geofencing, etc.

You can still run Android without GMS core and Play services -- I do that, myself, on a Pixel 3a running Graphene. The trick is that you lose some nice functionality (which Android actually makes up for in some cases, ie: SMS OTP copy buttons), and the mapping experience is god-awful (mostly because the OSS mapping scene is hopelessly stuck in the 1990s GPS model)

Post reply on HN