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”

A Look At Not An Android Emulator

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

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”

Bootstrapping Android Development: A Survival Guide

Developing Android applications seems like it should be fairly straightforward if you believe the glossy marketing by Google and others. It’s certainly possible to just follow the well-trodden path, use existing templates and example code – or even use one of those WYSIWYG app generators – to create something passable that should work okay for a range of common applications. That’s a far cry from learning general Android development, of course.

The process has changed somewhat over the years, especially with the big move from the Eclipse-based IDE with the Android Development Tools (ADT) plugin, to today’s Jetbrains IntelliJ IDEA-based Android Studio. It’s fortunately still possible to download just the command-line tools to obtain the SDK components without needing the Google-blessed IDE. Using the CLI tools it’s not only possible to use your preferred code editor, but also integrate with IDEs that provide an alternate Android development path, such as Qt with its Qt Creator IDE.

Continue reading “Bootstrapping Android Development: A Survival Guide”

The Browser Wasn’t Enough, Google Wants To Control All Your Software

A few days ago we brought you word that Google was looking to crack down on “sideloaded” Android applications. That is, software packages installed from outside of the mobile operating system’s official repository. Unsurprisingly, a number of readers were outraged at the proposed changes. Android’s open nature, at least in comparison to other mobile operating systems, is what attracted many users to it in the first place. Seeing the platform slowly move towards its own walled garden approach is concerning, especially as it leaves the fate of popular services such as the F-Droid free and open source software (FOSS) repository in question.

But for those who’ve been keeping and eye out for such things, this latest move by Google to throw their weight around isn’t exactly unexpected. They had the goodwill of the community when they decided to develop an open source browser engine to keep the likes of Microsoft from taking over the Internet and dictating the rules, but now Google has arguably become exactly what they once set out to destroy.

Today they essentially control the Internet, at least as the average person sees it, they control 72% of the mobile phone OS market, and now they want to firm up their already outsized control which apps get installed on your phone. The only question is whether or not we let them get away with it.

Continue reading “The Browser Wasn’t Enough, Google Wants To Control All Your Software”