7 ms·
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
by jmgao 11mo ago
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.
- itsnoone 11mo agoIt 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.
- a13n 11mo agois 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
- indentit 11mo agoSpecifications are there for a reason... Why use Bluetooth at all if they don't actually use it properly?
- helsinkiandrew 11mo agoYou can still connect AirPods to an android device using Bluetooth, you just don’t get the seamless connection or support for Spatial Audio that use the extended protocols
- Aurornis 11mo ago> Why use Bluetooth at all if they don't actually use it properly? Because they needed a way to get audio to the AirPods wirelessly and to work with their devices? That’s a pretty good reason to use Bluetooth. I doubt they got together and tried to scheme a way to break Bluetooth in this one tiny little way for vendor lock in. You can use the basic AirPod features with other Bluetooth devices. It’s just these extended features that were never developed for other platforms. HN comments lean heavily conspiratorial but I think the obvious explanation is that the devs built and tested it against iPhone and Mac targets and optimized for that. This minor discrepancy wasn’t worked around because it isn’t triggered on Apple platforms and it’s not a target for them.
- dabinat 11mo agoIt reminds me of the USB keyboard extender that came with old Macs. There’s a little notch in the socket so you can only use it with Apple keyboards. At the time I thought it was a petty way of preventing you from using it with any other device, but apparently the reason they didn’t want you to use it with other devices is because the cable didn’t comply with the USB spec. Some pictures here: https://www.reddit.com/r/assholedesign/comments/b1u08k/this_apple_usb_extender_has_a_bump_so_only_apple/ https://www.reddit.com/r/assholedesign/comments/b1u08k/this_...
- raw_anon_1111 11mo agoDid you even bother about reading the comments on your own citation?
- dabinat 11mo agoYes, I did actually. I genuinely don’t know what you’re referring to?
- dwaite 11mo agoYes, USB extenders are not spec-legal (because the device isn't built expecting to be extended). But you can have an extension cord which accepts USB on one end but doesn't accept USB on the other. So the keyboard has a superset connector so that it can go in regular USB and notched USB, because it is verified to work right when using the extension cord. This design also means you can't plug one extension cord into another to get an even longer distance (which the keyboard wouldn't expect). Pretty clever solution.
- binkHN 11mo agoThis is Microsoft's playbook from many years ago: embrace, extend, extinguish.
- fouc 11mo agoPerhaps Apple correctly implemented the specification here
- wolpoli 11mo agoApple is a promoter member of the Bluetooth standard organization for a while now, so it could submit that as an enhancement.
- Aurornis 11mo agoI doubt it’s for any reason at all. The obvious explanation is that they just developed and tested these extra firmware features against Apple devices because that was the product decision. Since nobody was tasked with targeting Android they might not have even noticed that it wasn’t perfectly spec-compliant if those states were never encountered, nor expected to be encountered.
- fouc 11mo agoAssuming they even went off spec at all.
- potatoproduct 11mo agoPerformance reasons LOL. Apple fans love plausible deniability.
- okayjustonemore 11mo agoAnd haters love a conspiracy. Truth is, no one has the full facts so any reasons as to why this was made the way it was is pure speculation. Only a fool would move to condemn or endorse what is not yet fully understood.
- monocasa 11mo agoAs someone who's implemented custom Bluetooth protocols, it's actually quite easy to condemn an Apple manufacturer ID check to expose custom services. And what do you mean by "conspiracy"? I would be shocked to find out this was done by some lone wolf and wasn't built with broad (even if grumbly) consensus in the relevant teams. That's how corporate software is built.
- okayjustonemore 11mo agoEvery time someone opens an argument with the classic appeal to authority “as someone who has…” you can almost certainly expect to have that person miss the point of the discussion entirely.
- monocasa 11mo agoWhat a fantastic way to keep from addressing anything I said while still allowing you to act condescendingly.
- gf000 11mo agoif (name == 'APPLE') will surely improve performance.
- fingerlocks 11mo agoNo there isn’t. I’ve said this a million times before, but usually just downvoted: this is about reducing support costs, not increasing revenue from lock-in. This is not a theory, I’ve sat in meetings at Cupertino and been told first hand. Support is very expensive. Say what you want about Apple, but they provide absolutely stellar support, especially with the stupidly inexpensive Apple Care insurance. This is only cost effective if they can make reasonable predictions about how their devices will behave in any given scenario. Interfacing Apple hardware with non-certified (MFi, BLE, etc) third party hardware has a non-trivial risk of unpredictability high support costs, either from excessive Apple Care claims, customer support communications, or just overloading the Genius Bar. Reducing support cost could easily explain the motivation of the entire walled garden if they are sufficiently high.
- pbhjpbhj 11mo agoThey couldn't just write (and make people aware at point of sale, ofc) 'no support for using devices with non-Apple Computers products' into Apple Care. They had to purposely break compatibility?
- bubblethink 11mo agoThat's tautological. Everything that is not supported is so because supporting it has a cost. The question is what is the cost? It seems quite obvious that the marginal revenue from airpods would be overshadowed by the revenue of getting a user in the ecosystem.
- fingerlocks 11mo agoCustomer support costs are higher at Apple than its competitors, because they provide a better support experience. This is not a tautology, it’s one of their core value propositions
- rangestransform 11mo agoHaving to test the AirPods with more standards compliant devices, having to waste time to tell customers to fuck off if their phone/laptop/toaster is not standards compliant, having to waste engineering time to investigate non compliant aliexpress phones/laptops/toasters, wasting time to implement additional functionality for Apple customers because it has to go into the spec first
- helsinkiandrew 11mo agoApple 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 https://www.usenix.org/system/files/woot20-paper-heinze.pdf
- xethos 11mo ago> They introduced some BLE features before the spec was finished In their defence, they went with Lightning shortly before the USB-C spec was finalized. Then, to avoid their customers being screwed over by constantly changing the connector, they kind of had to stick with it for a decade. People will complain if they push features that are ahead of the spec, and they'll complain if they let the spec be finalized before they use it. Being guided by "What's the best we can do for UX, assuming out users are our users in every product category we enter" seems to be their reasonable middle ground.
- bmandale 11mo agoboth scenarios speak to either an incredible impatience, or deliberate incompatibility to tie people to their ecosystem.
- binkHN 11mo agoIf Apple wasn't forced by the EU, they would try to preserve their walled garden as much as possible. iMessage is the prime example of this.
- raw_anon_1111 11mo agoCan another company federate with WhatsApp or Facebook Messenger?
- 11mo ago
- baxtr 11mo agowhen you’ve worked long enough in any given industry you know that all companies "violate" standards to satisfy requirements of their product management.
- jauntywundrkind 11mo agoIn 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 https://github.com/seemoo-lab/owl
- alickz 11mo agoYou make a good point Though I wonder why it works with Linux, which I assume doesn't have code for a special handshake specific to AirPods
- jorvi 11mo agoGoogle works around a ton of out-of-spec hardware / driver quirks for Android's ExoPlayer media player stack. So it is more than reasonable to expect Google to add a workaround for this.