leo60228

Is support for cross-fork stacked PRs coming in the near future? I was surprised that didn't come before the feature entered public preview, as it seems rather important for the feature to be useful on public repositories.

AirDrop is based on AWDL, which is a proprietary protocol that requires low-level access to the Wi-Fi radio to implement. Apple told the EU that they have long-term plans to migrate from AWDL to the standard Wi-Fi Aware, but have not yet done so (and the EU did not require them to, only that they bring their Wi-Fi Aware support for third-party apps to feature parity).

Things have inverted: iOS now has a user-visible filesystem apps can expose their data in, while current Android versions model everything around "documents" sourced from "document providers" with major performance and functionality limitations.

These rulings only affect third-party apps, not AirDrop. Apple is not required to stop using AWDL for system apps, and is also not required to allow third-party implementations of the AirDrop protocol. They are however required to implement a mechanism allowing competing solutions to automatically trigger a prompt to install their own iOS apps, but the deadline for that isn't until next year and they have not yet shipped it.

The Wi-Fi radio's firmware has to have special support for communicating via AWDL while staying connected to an access point. The blog post does say that they plan to expand support to other devices, though.

It does not. AirDrop, and to my knowledge all other Apple functionality, still uses AWDL. For backwards compatibility reasons, the EU did not require Apple remove AWDL, just that any improvements benefiting AWDL also affect Wi-Fi Aware. The EU also did not require Apple make AirDrop interoperable, only that they stop disadvantaging third-party competitors in certain ways (and those changes aren't implemented in iOS 26, the deadline for it is next year). Google's implementation was purely done via reverse-engineering, similarly to the existing OpenDrop project.

All of the code for this (including AWDL, at least to an extent) is implemented as part of Play Services, unfortunately.

Active monitor mode doesn't allow using AWDL while staying connected to a regular Wi-Fi network. That needs special firmware support.

They don't. Google implemented AWDL, as can be trivially proven by just running `strings` on the new code in Play Services.

From my understanding, it's relatively well known how to break Widevine L3, but nobody wants to release code (for obvious reasons). Widevine L1 is much better secured, as it's required to be implemented in hardware.

Isn't this feature what's blocking Bluetooth Passthrough on macOS Dolphin?