Android Developer Verification Starts As Google Partially Retreats On Measures

November 14, 2025 by Maya Posch 33 Comments

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

November 10, 2025 by Maya Posch 27 Comments

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

October 11, 2025 by Elliot Williams 93 Comments

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

October 6, 2025 by Maya Posch 162 Comments

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

September 15, 2025 by Maya Posch 8 Comments

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” →

A Look At Not An Android Emulator

September 10, 2025 by Fenix Guthrie 14 Comments

Recently, Linux has been rising in desktop popularity in no small part to the work on WINE and Proton. But for some, the year of the Linux desktop is not enough, and the goal is now for the year of the Linux phone. To that end, an Android Linux translation layer called Android Translation Layer (we never said developers were good at naming) has emerged for those running Linux on their phones.

Android Translation Layer (ATL) is still in very early days, and likely as not, remains unpackaged on your distro of choice. Fortunately, a workaround is running an Alpine Linux container with graphics pass through via a tool like Distrobox or Toolbox. Because of the Alpine derived mobile distribution postmarketOS, ATL is packaged in the Alpine repos.

In many ways, running Android apps on Linux is much easier then Windows apps. Because Android apps are architecture independent, hardware emulation is unnecessary. With such similar kernels, on paper at least, Android software should run with minimal effort on Linux. Most of what ATL provides is a Linux/Android hardware abstraction layer glue to ensure Android system calls make their way to the Linux kernel.

Of course, there is a lot more to running Android apps, and the team is working to implement the countless Android system APIs in ATL. For now, older Android apps such as Angry Birds have the best support. Much like WINE, ATL will likely devolve into a game of wack-a-mole where developers implement fresh translation code as new APIs emerge and app updates break. Still, WINE is a wildly successful project, and we hope to see ATL grow likewise!

If you want to get your Android phone to talk to Linux, make sure to check out this hack next!

The Android Linux Commander

September 9, 2025 by Al Williams 7 Comments

Last time, I described how to write a simple Android app and get it talking to your code on Linux. So, of course, we need an example. Since I’ve been on something of a macropad kick lately, I decided to write a toolkit for building your own macropad using App Inventor and any sort of Linux tools you like.

I mentioned there is a server. I wrote some very basic code to exchange data with the Android device on the Linux side. The protocol is simple:

All messages to the ordinary Linux start with >
All messages to the Android device start with <
All messages end with a carriage return

Security

You can build the server so that it can execute arbitrary commands. Since some people will doubtlessly be upset about that, the server can also have a restrictive set of numbered commands. You can also allow those commands to take arguments or disallow them, but you have to rebuild the server with your options set.

There is a handshake at the start of communications where Android sends “>.” and the server responds “<.” to allow synchronization and any resetting to occur. Sending “>#x” runs a numbered command (where x is an integer) which could have arguments like “>#20~/todo.txt” for example, or, with no arguments, “>#20” if you just want to run the command.

If the server allows it, you can also just send an entire command line using “>>” as in: “>>vi ~/todo.txt” to start a vi session.

Continue reading “The Android Linux Commander” →