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

Re:Android's new Bluetooth stack rewrite (Gabeldorsh) is wri... by yjftsjthsd-h on Wednesday March 31, 2021 @01:23PM (#26650142)

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 billions of dollars in R&D plus caring about quality makes a difference.

[ Parent | on HN ]

Re:Android's new Bluetooth stack rewrite (Gabeldorsh) is wri... by coryrc on Wednesday March 31, 2021 @02:18PM (#26650933)

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.

[ Parent | on HN ]

Re:Android's new Bluetooth stack rewrite (Gabeldorsh) is wri... by mondoshawan on Wednesday March 31, 2021 @01:55PM (#26650609)

Actually the spec is overspecified and repeats itself multiple times in different layers. L2CAP specifies a TTL, so does RFCOMM, so does SOC, so does...

[ Parent | on HN ]

Re:Android's new Bluetooth stack rewrite (Gabeldorsh) is wri... by fshbbdssbbgdd on Wednesday March 31, 2021 @01:27PM (#26650191)

I buy this. All Apple works great, but Apple headset with Windows PC doesn’t seem better than anything else with Windows PC.

[ Parent | on HN ]