LibrePods: AirPods Features on Linux and Android

What LibrePods replaces, and for whom

AirPods expose most of their interesting behaviour over a proprietary protocol that Apple devices speak. On Linux and Android, the earbuds still connect as ordinary Bluetooth audio devices, but the control channel that carries listening mode changes, battery readings and ear detection events is not used. LibrePods implements that protocol, so the features stop being Apple-exclusive. The README frames the goal plainly: it enables features like changing noise control modes, fast ear detection, accurate battery status, head gestures and conversational awareness on non-Apple platforms.

The audience is narrow and specific. You need AirPods, and you need to be running Linux or Android as the host. The repository splits into an android/ directory and a linux/ directory, with a root-module-manual/ entry and an extras/ directory alongside them. The topics list confirms the intent: android, linux, battery-monitor, ear-detection, hearing-aid, reverse-engineering. This is a reverse engineering project first, and a consumer app second.

How the protocol implementation is organised

The project is written in Kotlin and builds two targets from one repository. The Android side is a Kotlin application; the Linux side is a Rust component, which is visible from the CI workflow names in the README: ci-android.yml and ci-linux-rust.yml. That split matters when you read the feature table, because the two columns do not match.

Listening mode changes, ear detection, battery status, renaming, conversational awareness and automatic connection are marked as implemented and working on both platforms. Everything else diverges. Head gestures are implemented on Android and will not be implemented on Linux. The accessibility group (press speed, press and hold duration, noise cancellation with a single AirPod, volume control on swipe, volume swipe speed) and the general configuration group (call controls, personalised volume, microphone side, and others) are Android-only, and several of those entries carry the white circle symbol, meaning they need VendorID spoofing.

VendorID spoofing is the mechanism worth understanding before you install anything. The README explains that changing the VendorID in the DID Profile to Apple's makes several special features available. On Linux this is a configuration change; on Android it is a setting inside the app that only appears when Xposed is available and the LibrePods module is enabled. That gate is the single biggest difference between a quick install and a full one.

Installing on Android and pairing the first time

The README points to two installation documents, /android/README.md and /linux/README.md, rather than giving steps inline. The Android build is distributed as an APK, and the repository publishes release artifacts including v1.0.0-rc1 and nightly builds. The README does not inline an install command, so the APK comes from the releases page linked in the README header.

After installation, open the app and connect your AirPods through the normal Android Bluetooth pairing flow. The app should detect the earbuds and begin reporting battery status and ear detection. If you want the settings that require Apple's VendorID, the README says you enable the "act as Apple device" setting in the app's settings, and that this option is shown only when Xposed is available and the LibrePods module is enabled. Without that, expect the core features only.

One Android-specific caveat is documented for renaming: after you rename the AirPods, you need to re-pair them, because Android might not pick up the latest name.

Installing on Linux and enabling VendorID spoofing

The Linux path is documented in /linux/README.md and is built from Rust. The README does not inline the build commands, so the install document is the place to check for the current procedure. What the README does give inline is the VendorID change, which is a single line added to the Bluetooth configuration file.

# Add this line to /etc/bluetooth/main.conf
DeviceID = bluetooth:004C:0000:0000

That value is the Apple vendor identifier, and the README states that changing the VendorID in the DID Profile to Apple's grants access to several special features. Editing /etc/bluetooth/main.conf affects the whole system's Bluetooth identity, not just LibrePods, so it is a system-level change rather than an app setting. The README does not document a rollback procedure for this edit, and it does not describe what other Bluetooth devices on the same machine do once the vendor ID changes.

The Linux column of the feature table is thinner than Android's. Head gestures will not be implemented, and the accessibility and general configuration groups are marked as not implemented yet and planned. Hearing aid support is also marked as planned on Linux.

What is not implemented, and where the project stops

The feature table is unusually honest, and reading it carefully saves disappointment. High quality two-way audio is marked as not implemented on both platforms. The README explains why: on iOS and iPadOS you can keep using A2DP while the AirPods send microphone audio over AACP, and reproducing that on Android needs deeper integration with the audio stack, which will most likely need root. That is a structural limitation, not a backlog item.

Spatial audio is a separate boundary. The README states that the app does not currently provide head tracking information to Android for the OS to perform HRTF, that this has not been explored completely, and that it might need root. It then draws a hard line: spatializing stereo sound is beyond the project's scope and will never be available, because many OEMs have their own implementation. The table marks head-tracked spatial audio as unknown on both platforms.

Find My is planned but not present. The README lists adding AirPods to the Find My network, playing a sound through the charging case, leave-behind notifications and case charging sound toggles as requiring further reverse engineering and possibly root on Android. Heart rate monitoring on AirPods Pro 3 and later is being worked on, with the README pointing to the reverse-engineering channel on the project's Discord server, and noting it will most likely need root on Android. The feature table marks it as will not be implemented on Linux and not implemented yet on Android.

Multi-device connectivity and how it compares to staying in Apple's ecosystem

Multi-device connectivity is listed in the table with a white circle on both platforms, meaning it needs VendorID spoofing. The README describes the behaviour in more detail: up to two devices can be connected to the AirPods simultaneously, for audio and control, with connection switching, and the same notification appears on an Apple device when Android takes over the AirPods, phrased as "Move to iPhone". Android also shows a popup when the other device takes over. That is a two-device limit, not the broader multipoint some headphones offer.

The natural alternative is simply to keep using an Apple device as the host, where all of this works without reverse engineering. The difference in approach is not feature parity; it is who owns the protocol implementation. Staying in Apple's ecosystem means the control channel is supported by the vendor and updates arrive with the OS. LibrePods means you depend on a community implementation of a protocol that was never published, running on platforms Apple does not target. The README's own warning about a third-party site claiming to be official is a reminder that this is a small project with a real maintainer and an email address for reports, not a company with a support organisation.

Licence, maintenance and the cost of upgrades

The repository is licensed GPL-3.0. That is a copyleft licence, so if you redistribute a modified version of LibrePods, the source for your version has to be made available under the same terms. Running it on your own phone or laptop does not trigger that obligation. If you are considering embedding this in a product, the licence is the first thing to raise with someone qualified to advise on it, because the obligations differ from permissive licences.

On maintenance, the repository is not archived. The last push was on 2026-09-01, and the most recent release listed is a nightly from 2026-08-31, with v1.0.0-rc1 from 2026-06-20 before it. Nightly builds mean the project ships continuously rather than on a stable cadence, so upgrading means tracking nightly artifacts unless you deliberately stay on the release candidate. The README's feature table is the thing to re-read after an upgrade, because entries can move between planned and implemented without a version bump that announces it. The root-module-manual/ directory in the repository root suggests there is a manual, root-dependent path documented separately from the main install guides.

Editorial conclusion

LibrePods is for people who own AirPods and use Linux or Android as their daily driver, and who accept that the Linux side is a smaller feature set with several items marked as planned. It is not for anyone who needs hearing aid support, spatial audio with head tracking, or high quality two-way audio today, since the README lists those as unimplemented or unknown. Before installing, check the feature table for your platform, and on Android decide whether you are willing to install the Xposed module, because the settings that need VendorID spoofing are gated behind it.

Frequently asked questions

Official sources

1. Issues
2. librepods-org/librepods on GitHub
3. License: GPL-3.0
4. README
5. Releases