It doesn't seem obvious to me that this is actually a bug in the Android implementation, it seems like this is due to AirPods violating the spec and requiring a special handshake before responding to standard requests. It doesn't seem reasonable to expect Android to work around a device that appears to be intentionally breaking the spec for vendor lock-in purposes: the possibility of them just OTAing an update that breaks in some other way means that you'd have to be entirely bug compatible with iOS's bluetooth implementation.

It not that hard to imagine Apple going out of their way to do something that would break functionality on Android, honestly. Although, I believe Fluoride also is to be blamed here because a simple timeout can not possible cause any issues (it seems that a timeout is there, but never called- at least from my tinkering). I am not planning to spend a single second tracing back the actual problem and suggesting a fix, given that Google just asked me to reproduce twice (!!) and did nothing about it.

when you’ve worked long enough in any given industry you know that all companies "violate" standards to satisfy requirements of their product management.

Apple have been ‘extending’ the Bluetooth stack for quite awhile. They introduced some BLE features before the spec was finished (I think some 3rd party hearing aids were also compatible).

I haven’t used non apple earphones for awhile but the seamless connectivity performance of AirPods would suggest this was done for performance, not to deliberately lock in devices.

This 2020 paper is great at breaking down some of the extensions: https://www.usenix.org/system/files/woot20-paper-heinze.pdf

is there evidence it’s for vendor lock in purposes? airpods have a pretty stellar connection for bluetooth, wouldn’t be surprised if there were performance reasons for them going off spec

In general, rigidity of stack is a malfeasance. Over protecting the user brings fragility, un-adaptability, that curses the world. Android certainly is a rigid narrow protective stack that refuses to accommodate, again and again. Different genre, but decades latter and it still won't work on many ipv6 networks because for no clearly stated reason it won't support DHCPv6: Android is full of these weirdly unstated "principled" anti-compatibilities, and I can't excuse blaming the devices or networks for being what they are: it's the unbending rigid OS that offends me.

I do rather hope perhaps perhaps perhaps the EU & DMA or other may perhaps bend Apple off their rotten course of making non-standard bespoke systems. It seems like very recently the EU is getting ready to cave & abandon all their demands for trying to use standards, that their fear of the US is about to make them fold on insisting upon better. Demanding Apple stop doing everything in bespoke incompatible ways is something that should have happened a long time ago, imo, and it's so horrifying to see one of the only stands in my lifetime against the propeietarization & domination of systems by a bespoke corporate lord abandoned.

There's some rays of hope here & there. Seemoo Lab has a ton of amazing reverse engineering efforts, figuring out how many many many undocumented locked down Apple systems & protocols work & trying to give control back. This is the highest virtue, the best hacker nature. Here's Open Wireless Link, but they have so many other amazing projects they've similarly figured out out to pry open. Amazing best human spirit. https://github.com/seemoo-lab/owl