Liberating AirPods With Bluetooth Spoofing

Apple’s AirPods can pair with their competitors’ devices and work as basic Bluetooth earbuds, but to no one’s surprise most of their really interesting features are reserved for Apple devices. What is surprising, though, is that simple Bluetooth device ID spoofing unlocks these features, a fact which [Kavish Devar] took advantage of to write LibrePods, an AirPods controller app for Android and Linux.

In particular, LibrePods lets you control noise reduction modes, use ear detection to pause and unpause audio, detect head gestures, reduce volume when the AirPods detect you’re speaking, work as configurable hearing aids, connect to two devices simultaneously, and configure a few other settings. The app needs an audiogram to let them work as hearing aids, and you’ll need an existing audiogram – creating an audiogram requires too much precision. Of particular interest to hackers, the app has a debug mode to send raw Bluetooth packets to the AirPods. Unfortunately, a bug in the Android Bluetooth stack means that LibrePods requires root on most devices.

This isn’t the first time we’ve seen a hack enable hearing aid functionality without official Apple approval. However, while we have some people alter the hardware, AirPorts can’t really be called hacker- or repair-friendly.

Thanks to [spiralbrain] for the tip!

Google Is Building A New OS

Windows, macOS, and Linux are the three major desktop OSs in today’s world. However, there could soon be a new contender, with Google stepping up to the plate (via The Verge).

You’ve probably used Google’s operating systems before. Android holds a dominant market share in the smartphone space, and ChromeOS is readily available on a large range of notebooks intended for lightweight tasks. Going forward, it appears Google aims to leverage its experience with these products and merge them into something new under the working title of “Aluminium OS.”

The news comes to us via a job listing, which sought a Senior Product Manager to work on a “new Aluminium, Android-based, operating system.” The hint is in the name—with speculation that the -ium part of Aluminium indicates its relationship to Chromium, the open-source version of Chrome. The listing also indicated that the new OS would have “Artificial Intelligence (AI) at the core.” At this stage, it appears Google will target everything from cheaper entry level hardware to mid-market and premium machines.

It’s early days yet, and there’s no word as to when Google might speak more officiously on the topic of its new operating system. It’s a big move from one of the largest tech companies out there. Even still, it will be a tall order for Google to knock off the stalwart offerings from Microsoft and Apple in any meaningful way. Meanwhile, if you’ve got secret knowledge of the project and they forget to make you sign an NDA, don’t hesitate to reach out!

Android Developer Verification Starts As Google Partially Retreats On Measures

In a recent blog post Google announced that the early access phase of its Android Developer Verification program has commenced, as previously announced. In addition to this new announcement Google also claims to be taking note of the feedback it has been receiving, in particular pertaining to non-commercial developers for whom these new measures are incredibly inconvenient. Yet most notable is the ’empowering experienced users’ section, where Google admits that to developers and ‘power users’ the intensive handholding isn’t required and it’ll develop an ‘advanced flow’ where unverified apps can still be installed without jumping through (adb) hoops. Continue reading “Android Developer Verification Starts As Google Partially Retreats On Measures”

Testing Whether Fast Charging Kills Smartphone Batteries, And Other Myths

Calendar aging of NMC Li-ion cells at 50 ℃ at various SoCs. (Credit: Wiljan Vermeer, IEEE, 2021)
Calendar aging of NMC Li-ion cells at 50 ℃ at various SoCs. (Credit: Wiljan Vermeer, IEEE, 2021)

With batteries being such an integral part of smartphones, it’s little wonder that extending the period between charging and battery replacement has led to many theories and outright myths about what may affect the lifespan of these lithium-ion batteries. To bust some of them, [HTX Studio] over on YouTube has spent the past two years torturing both themselves and a myriad of both iOS and Android phones to tease out some real-life data.

After a few false starts with smaller experiments, they settled on an experimental setup involving 40 phones to investigate two claims: first, whether fast charging is worse than slow charging, and second, whether limiting charging to 80% of a battery’s capacity will increase its lifespan. This latter group effectively uses only 50% of the capacity, by discharging down to 30% before recharging. A single control phone was left alone without forced charge-discharge cycles.

Continue reading “Testing Whether Fast Charging Kills Smartphone Batteries, And Other Myths”

Easy For The Masses

Last week, we were talking about how glad we are to be the type who by-and-large understands technology, and how it’s becoming more and more difficult to simply get along otherwise. We thought we had a good handle on the topic.

Then, we were talking about Google’s plans to require an ID for Android developers, and whether or not this will shut down free and open software development on the Android platform. Would this be the end of the ability to run whatever software that you’d like on your phone? Google offered the figleaf that “sideloading” – installing software through methods other than Google’s official store, would still be be allowed. But there’s a catch – you have to use Android Debug Bridge (ADB).

Is that a relief? It surely means that I will be able to install anything I want: I use ADB all the time, because it’s one of the fastest and easiest ways to transfer files and update software on the device. But how many non-techies do you know who use ADB? We’d guess that requiring this step shuts out 99.9% of Android users. If you make software hard to install for the masses, even if you make it possible for the geeks, you’re effectively killing it.

I have long wondered why end-to-end encrypted e-mail isn’t the default. After all, getting a GPG signing key, distributing it to your friends, and then reading mail with supporting software shouldn’t be a big deal, right? If GPG signing were available by default in Outlook or GMail, everyone would sign their e-mail. But there is no dead-simple, non-techie friendly way to do so, and so nobody does it.

Requiring ADB to load Android software is going to have the same effect, and it’s poised to severely restrict the amount of good, open software we have on the platform unless we can figure out a way to make installing that software easy enough that even the naive users can do it.

Google Confirms Non-ADB APK Installs Will Require Developer Registration

After the news cycle recently exploded with the announcement that Google would require every single Android app to be from a registered and verified developer, while killing third-party app stores and sideloading in the process, Google has now tried to put out some of the fires with a new Q&A blog post and a video discussion (also embedded below).

When we first covered the news, all that was known for certain was the schedule, with the first trials beginning in October of 2025 before a larger rollout the next year. One of the main questions pertained to installing apps from sources that are not the Google Play Store. The answer here is that the only way to install an app without requiring one to go through the developer verification process is by installing the app with the Android Debug Bridge, or adb for short.

The upcoming major release of Android 16 will feature a new process called the Android Developer Verifier, which will maintain a local cache of popular verified apps. The remaining ones will require a call back to the Google mothership where the full database will be maintained. In order to be a verified Android developer you must have a Google Play account, pay the $25 fee and send Google a scan of your government-provided ID. This doesn’t mean that you cannot also distribute your app also via F-Droid, it does however mean that you need to be a registered Play Store developer, negating many of the benefits of those third-party app stores.

Although Google states that they will also introduce a ‘free developer account type’, this will only allow your app to be installed on a limited number of devices, without providing an exact number so far. Effectively this would leave having users install unsigned APKs via the adb tool as the sole way to circumvent the new system once it is fully rolled out by 2027. On an unrelated note, Google’s blog post also is soliciting feedback from the public on these changes.

Continue reading “Google Confirms Non-ADB APK Installs Will Require Developer Registration”

Going Native With Android’s Native Development Kit

Originally Android apps were only developed in Java, targeting the Dalvik Java Virtual Machine (JVM) and its associated environment. Compared to platforms like iOS with Objective-C, which is just C with Smalltalk uncomfortably crammed into it, an obvious problem here is that any JVM will significantly cripple performance, both due to a lack of direct hardware access and the garbage-collector that makes real-time applications such as games effectively impossible. There is also the issue that there is a lot more existing code written in languages like C and C++, with not a lot of enthusiasm among companies for porting existing codebases to Java, or the mostly Android-specific Kotlin.

The solution here was the Native Development Kit (NDK), which was introduced in 2009 and provides a sandboxed environment that native binaries can run in. The limitations here are mostly due to many standard APIs from a GNU/Linux or BSD environment not being present in Android/Linux, along with the use of the minimalistic Bionic C library and APIs that require a detour via the JVM rather than having it available via the NDK.

Despite these issues, using the NDK can still save a lot of time and allows for the sharing of mostly the same codebase between Android, desktop Linux, BSD and Windows.

Continue reading “Going Native With Android’s Native Development Kit”