They don't report battery status to non-Apple devices. This is a pretty basic feature and without this I wouldn't consider them to perform "on par" with other Bluetooth headphones.
You're proving the parent commenter's point that "this is about availability of special features which require a dedicated driver non-Apple devices are not expected to have", because there is no standard way in BLE to report more than one battery value. Wireless earbuds are a device pair, each with its own battery.
Apple, like every other vendor, does not have a choice but to implement this as a proprietary characteristic. Pre-BLE, other vendors copied Apple's de-facto `HFP AT+IPHONEACCEV` standard for reporting battery levels to the OS.
> Apple, like every other vendor, does not have a choice but to implement this as a proprietary characteristic. Pre-BLE, other vendors copied Apple's de-facto `HFP
They could publish the details, and not block other manufacturer details, so that it is easier for other platforms to develop drivers for them. Or develop a new standard that works for their earbuds.
I wonder how well that conversation detection works. Does it really help in a loud environment?
As a neurodivergent person I lack the innate human skill to filter voices out of a cacaphony of noise so loud bars etc are hell. There also the "talking with earphones in is rude" but that's an issue that can just be explained.
Needing root to enable it is a major deal-breaker though :( and moving to an iPhone is impossible for me. Too much stuff that's not supported.
Or Apple just doesn't want to bother with the nightmare of supplying and supporting an app to do all those things on other platforms, and in particular, there are regulatory approvals around the "hearing aid" feature that would pretty much require a specific device.
They have a basic app for some of their other devices like the Beats line. One other thing you simply can't do without pairing AirPods with an Apple device is enrol them in AppleCare One.
You're commenting on a post where a random guy provides this "nightmare of supplying and supporting an app" in his spare time, except he actually has to work around Apple's malicious obfuscation and standards non-compliance, so it would actually be way easier for Apple to do it themselves.
From what it says, a rooted device is required because Apple made them behave differently depending on the host. Apple wouldn't have needed a rooted Android device to support all the features.
Are you saying this would the first time an unpaid open source effort has done something a big company declined to do because of the operational costs they face?
It is in fact significantly harder for Apple. Because nobody expects random spare time GitHub project to work perfectly. Or even very well. Apple’s reputation, and trillion dollar market value, is based on the idea that their stuff works perfectly.
good god man, just accept that this is objectively an EXTREMELY easy thing to do for anyone. Yes theoretically there are things that are easier for OSS devs than large companies, THIS AIN'T ONE OF THEM.
Ugh, trillion dollar market value doesn't mean they are incapable of making a basic android app. Check their move to ios app if you have any doubts.
It doesn’t matter how frustrated you get or how many times you write capital letters, Apple is a private company and can do exactly what they want to do. If you would like Apple to do your bidding, acquire a controlling interest - it’s public so there’s nothing stopping you.
Welcome to this argument which is about how easy/hard it might be for a company to implement this particular feature.
The argument about whether they ought to is in some other thread I imagine, you might have lost your way. I don't own their airpods so in this particular instance, IDC about the outcome.
Are you aware they are maintaining multiple complete OSs, and multiple versions of each? With drivers for hundreds of components? The scope of AirPods on Android is laughable in comparison.
You're responding in a sub-thread where others have specifically called out the fact that you can't get battery status from AirPods on non-Apple platforms. This is, to my knowledge, a feature that is supported natively by the Bluetooth stacks on every mainstream OS and requires no "apps" at all. For example, I can connect my Bluetooth mouse to my Linux machine and it happily reports the state of the battery.
Care to offer a justification for why this is the case without resorting to "the multi-trillion-dollar behemoth can't be bothered to build an app"?
The multi battery levels thing is native proprietary on every platform since there is no Bluetooth spec for more than one battery level and even that just uses uint8.
As I posted elsewhere in the thread, this is incorrect. The Bluetooth Battery Service spec allows for a single device with multiple batteries and individual battery reporting for each. [0] They even give the example in that doc of earbuds which are one “logical device” but two physically separate pieces, each with its own battery.
As additional evidence, there are "AirPods-like" earbuds on the market such as the Sony WF-C700N, which have no problem reporting three battery levels over standard Bluetooth on e.g. Linux.
The Bluetooth Battery Service spec allows for a single device with multiple batteries
As of version 1.1 of the battery service which was finalized at the end of 2022. Given Bluetooth's track record, who knows what kind of interoperability landmines exist.
If you don't like the Apple device, use something else. It's not like a messaging platform where you'd need compatibility with other peoples' phones.
If you'd bothered to dig into the spec, v1.0 basically says do what you want. v1.1 defines a proper namespace and well known descriptions for multiple batteries. Apple did well to avoid the interoperability minefield.
> If you don't like the Apple device, use something else. It's not like a messaging platform where you'd need compatibility with other peoples' phones.
I own and use lots of devices, for both work and personal tasks, including Apple and non-Apple devices. I own a pair of AirPods. I'd like them to work well across all the platforms that I use. There is nothing technically preventing Apple from achieving this, aside from Apple's arguably illegal tying behavior.
> If you'd bothered to dig into the spec, v1.0 basically says do what you want. v1.1 defines a proper namespace and well known descriptions for multiple batteries. Apple did well to avoid the interoperability minefield.
I have read the spec; please don't accuse me of not reading it. Have you written Bluetooth device firmware before? In case you haven't, at a high level:
* The BT device exposes a "profile," which defines one or more "services", which are essentially different types of data that can be read from or written to the device.
* Multiple instances of the same type of service (the Battery Service in this case) can be exposed in the profile. I don't know if this ability was always present in the spec or was added after the fact, but it was, at minimum, present in 2011 when the BAS 1.0 spec was released.
* So, if your device has more than one battery, its profile will have an instance of the Battery Service defined for each one.
I will grant that the 1.1 spec document is a lot clearer and provides lots of diagrammed examples, but the only net new functionality in 1.1 are a set of new battery-related fields (these are called out near the beginning).
When a device has more than one instance of the Battery service, each Battery
Level characteristic shall include a Characteristic Presentation Format
descriptor that has a namespace/description value that is unique for that
instance of the Battery service.
1.1 says:
When a device has more than one instance of the Battery Service, each Battery
Level characteristic shall include a Characteristic Presentation Format descriptor
(Volume 3, Part G, Section 3.3.3.5 in [1]) that has the Name Space field set to
”Bluetooth SIG” and the Description field set to a valid value from the GATT
Namespace Descriptors [4] and that is unique among all instances of the Battery
Service exposed by the GATT Server.
1.0 was a mess and your anger over a poorly defined and relatively minor feature seems quite misplaced. Bluetooth interoperability has historically been a mess (still is from my experience). But go ahead be big mad that Airpods only play audio from third party devices and don't provide battery status in a way that adheres to a recent revision of the standard. Meanwhile I'm sure Sony would never use a proprietary format ever…
I had posted a reply addressing your points, but I don't think this discussion is productive and you don't seem to want to engage honestly with what I'm saying and stay on topic. So I'll just say have a good day.
So they refuse to report anything useful rather than make use of the single battery level. Amazingly every other brand of Bluetooth earbuds manage to report a useful battery level despite them having a separate battery in each side.
The Bluetooth spec only supports one battery status. AirPods have three batteries. Is 1 < 3 a satisfactory enough answer to you?
On the subject of the multi-trillion-dollar behemoth, Apple is a private company. If you have the capital, you can acquire a controlling interest and then they’ll work on whatever you like. Until then, you’re out of luck.
> The Bluetooth spec only supports one battery status. AirPods have three batteries. Is 1 < 3 a satisfactory enough answer to you?
No, it's not. The Bluetooth Battery Service spec allows for a single device with multiple batteries and individual battery reporting for each. [0] They even give the example in that doc of earbuds which are one “logical device” but two physically separate pieces, each with its own battery.
> On the subject of the multi-trillion-dollar behemoth, Apple is a private company.
Apple is, by definition, a public company.
> If you have the capital, you can acquire a controlling interest and then they’ll work on whatever you like. Until then, you’re out of luck.
No. Anticompetitive behavior such as tying (what I would argue is happening here) can and should always be subject to examination, criticism, and possible litigation by the public.
Always this sad argument that X is a private company and they can do what they like.
Companies are not acts of God or nature. They are a private company operating on a society that allows it to exist because it is believed to be the for the public good. The public has very much the right to question it's practices, and if they are anti consumer, monopolistic, or a list of other things, to correct them. Shareholders be damned.
So what's your argument then? Companies can't release a product unless each and every feature works with their competitors products? By that logic most of the software and hardware you use today simply would not exist.
Like a lot of parts of the (especially earlier revisions of) Bluetooth spec the battery status took a slapdash approach to defining things. Look at anyone who's used Bluetooth on Windows to see what a nightmare interoperability still is. So Apple released ear buds that implement poorly defined parts of the spec but otherwise work with third party bluetooth devices, and that's bad?
Yikes.
Meanwhile, the Bluetooth SIG released an update at the end of 2022 that actually starts to require some sort of standardization. You know who's name was on that little update? Big bad awful anticompetitive Apple.
Yeah, there are two batteries, the one in the earbuds and the one in the container. There's no way in BLE to transmit both values - and choosing either one is lying to the user about something.
It's not uncommon (at least for me) to have a low earbud battery level (because I've just binged Slow Horses) or a low container battery (because I've just charged the earbuds from the container for the third time and drained the container). There's a suggestion above that you should "just choose the lowest one because 99% of the time that's what you're interested in", except that's not true in the second case.
I'm fairly sure that if you could report both, then Apple would report both using this hypothetical standard method, but since you can't, and there's no easy way to just "choose one" without misleading the user about something, they choose to do it properly, even though that means it's an Apple-only thing.
See my other replies in this thread — it’s totally possible to do with standard Bluetooth, yet Apple doesn’t do it. So your “fairly sure” assumption that Apple would make use of this feature if it existed seems to be wrong.
What "other platforms" are you talking about? Just an Android app would suffice. It's not a huge deal for a company worth trillions, especially if the features are already there and they're just blocking non-Apple products. If they deliberately do that, it makes you think they don't really care about their customers and are more interested in locking people into their ecosystem.
Not just non-Apple devices. I have a machine with older MacOS and the current Apple keyboard doesn't report battery status. I can't think of a reason why that would work differently from Apple's own older keyboards, but it does.
It's great that Microsoft added this as an official feature but there has been an open-source third-party solution that does exactly the same thing for a long time: https://github.com/dotnet-script/dotnet-script
I take the opposite approach - bundling is a non-starter for me. But it really depends on what you're building. Bundling can be great for web apps, but for content-driven websites where SEO optimization is key, I prefer the "90s-style" approach and Fullsoak's philosophy.
Also, separate HTTP requests allow for granular caching, and with HTTP/2 the overhead is minimal.
You're doing the opposite of SEO optimization if page speed score is of any value to your SEO (and it's important to Google's SEO ranking, so yeah). I work on a "content-driven website" - actually a few thousand of them - and our clients definitely want their SEO to be top-notch and page speed score factors into that. Any http requests for external resources will bring page speed down, and that can affect SEO. I don't have to worry about caching at all when the pages are scoring perfect 100% on Lighthouse.
Ortholinear is what you are referring to and it is absolutely worth it to learn. Staggered keyboards don’t make sense anymore - the originally reason keys were staggered was because the bars could not physically overlap - and it is far more natural to type only moving each finger along two axis
With the UHK I am already having difficulty typing directly on my MacBook. With the ortholinear this might only make switching back and forth harder. But it is intriguing.
Or easier. I have switched to column stagger pretty quickly after going to ergo keyboards and I don't have trouble typing on my MacBook. I only dread it now :).
Tried this as well but the difficulty is that Postgres is a relational database whereas ElasticSearch stores schema-less documents.
Your record in ES might include data from many different tables, and figuring out what to (efficiently) update when there is a change in Postgres is not a simple task.
For me, a shotgun approach seemed the least likely to break.
Anything that is a dependency in the elastisearch index should trigger a job to export to it. And since it is idempotent it doesn't matter if it accidentally exports two or ten times the same index in a bg job. Just make sure before writing that you do a quick check that you're not overriding a fresher one. So just have a freshness timestamp which is the latest timestamp of any record used in the indexing data.
Furthermore you can do a daily job to just re export a critical part of the index. Doesn't matter if it is or isn't fresh. So let's say you query all records that were modified in the last day, and trigger the export job thatnmaynincludebthat record. Even if it causes duicate work. Idempotency saves you there.
Perhaps include a "last modified" timestamp w/ timezone in tables of interest, PG can update this on a trigger so no app code has to change. Index this field. Then build a view on top of the relevant tables that assembles the document for ES. Include in the view a field which contains the most recent of all the "last modified" dates, and filter the view on that timestamp?
I don't think any KVM supports Bluetooth. You either need to use software like Barrier or get devices that can switch between multiple. The other option is wireless peripherals that use a USB dongle can work fine with KVMs like the ones Logitech sells.
That's the story of my life, unless you speak French you will probably pronounce my name wrong, no matter how many times I repeat it and help people pronounce it, I don't get mad nor think it's rude, it's kind of amusing actually. Once I realize they can't handle it I just tell people to call me by my last name which is very easy to say in English. There are too many interesting things in life to get hung up on a petty detail like a name.
Hey if you write your name out as LAST First (which I see many French people do) then you might not even have to ask people to call you by your first name.
Most of the time (and all of the time with gendered pronouns), you don't use it to address me. You're using it to talk about me. And then, it's really between you two what you call me, isn't it? Of course I would be happier knowing you didn't refer to me in a rude manner, or as something I'm not, but I believe in privacy too, so it's really your business.
Turkey isn't rude, and it's usually understood from context that we don't refer to the bird (the Turkish government also push Türkiye on countries where the native word has no bird connotation). We used to translate all names, and that's understandable because names are often unpronounceable or otherwise violate grammatical rules if you just blindly drop them in a different language. I think it should be fine to use "Turkey" when talking to another English-speaker.
It's a bit more complicated than that. It is also quite rude of you, where you not to not accept that other people write using other letters have have other abilities in terms of what phonemes they can pronounce.
I see a distinction between mapping a name more or less faithfully to the sounds and spelling of a language and coming up with a completely different name. For example Brazil in English is not the same as Brasil but is fairly close and fits the language. Whereas IDK where Germany came from.
I'm not a fan of this modern idea that you should get to dictate how others refer to you. E.g. I don't think it makes sense to refer to China as Middle Country for anyone not from China.
Sometimes, sometimes not. Everybody changed Peking to Beijing when China requested that. But living in Netherland, I shake my head at all the languages insisting on pluralising the name of my country. And that's not even addressing "Dutch".
I'm 100% opposed to telling people how to speak their language. I don't even like telling people who use English as a lingua franca how to use it in a culturally "correct" way.
Normally, I'm outspoken against most "domestic" proposals to change words, since the rationale and implementation are usually very poor.
But as an American, I've decided that Turkiye without the ü is more desirable than Turkey. It resolves an annoyingly ambiguous search term, doesn't change anything about how it's pronounced, reads the exact same way, and it's trivial to switch how I write it. It really is a superior design with a painless transition.
