lmemsm

Was recently commenting on a forum about how few Open Source alternatives there are for Android devices. The Free Software Foundation even had a wiki page about how development for mobile devices was a priority. However, when I wrote to them on the subject, they didn't bother to acknowledge or answer my e-mail (until just recently, two years later).

There are some good Open Source projects out there for Android. However, many commercial apps and even the Open Source applications appear to be trying to reinvent the wheel. They're redeveloping concepts that have already been done in other languages and with other build systems. Worse yet, they're making a lot of the same programming mistakes of earlier projects without learning from them.

I truly believe that taste varies widely as far as what people like in a program or application. To one person, an expensive commercial office suite or graphics program is a highly necessary tool. To someone else, it's too complicated and tries to do too much at once. What one person feels is a compelling, action-packed and exciting video game can be boring and mindless to another person. With that said, I'm sure my taste in programs does not match what many others are looking for. Personally, I do find the Open Source applications I ported from other operating systems to Android to be among my favorite Android apps. I'd love to find to locate other projects that are working on similar ports of popular Open Source applications.

Since I'm primarily interested in C/C++ development at this time and I've always been an advocate of cross-platform programming, I've been searching for good references and examples of C/C++ application development for Android that do not lock the developer into using a specific IDE or build system. Most books on Android development are for Java or Kotlin. There are even a good number that use web apps or web development languages likes JavaScript/HTML/CSS including projects like PhoneGap, ReactNative, NativeScript, etc.

There are very few books on NDK development for Android. All of the books I've found so far detail development with Android Studio (or Eclipse for older books that have not been updated in a while). SDL is typically mentioned with NDK development even though there are other development libraries that work with Android. Some don't mention libraries like SDL at all, but then you're limited to examples similar to those provided by Google or very basic applications. There are a few interesting articles on porting applications from other operating systems to mobile devices, but I've found no books that specialize or give much in the way of advice in this area.

I've been considering writing an e-book that fills in the gaps and gives examples of how to develop cross-platform applications that easily port to Android and use NDK plus a more a standard tool-chain. The only thing holding me back is the idea that there would probably be very few developers other than myself interested in this sort of thing. Obviously groups like the FSF weren't interested or they would have taken the time to answer an e-mail. If there is interest from other developers on sharing this type of information, please let me know.

I mentioned on a forum how much I'd like to see a list of available Open Source applications for Android (preferably cross-platform portable applications written in languages other than Java). It would be nice to see what others have done and get ideas for development based on them. Since I really haven't been able to find a resource like that, I'm putting together the start of such a resource here:

C/C++ SDL based apps ported to Android:
https://github.com/pelya/commandergenius
https://sourceforge.net/projects/libsdl-android/files/apk/
Terminal emulator in Java and cli and ncurses based applications ported from other systems:
https://github.com/termux/termux-packages/tree/master/packages
VLC for Android:
https://www.videolan.org/vlc/download-android.html
List of Open Source Android applications. Includes information on language the program was written in. While there aren't a lot of C/C++ applications listed there are some:
https://github.com/pcqpcq/open-source-android-apps
Similar list for iOS Apps:
https://github.com/dkhamsing/open-source-ios-apps
Another list of Open Source applications (unfortunately no indication of the languages they were written in or the build systems required):
https://en.wikipedia.org/wiki/List_of_free_and_open-source_Android_applications
Project for mobile devices (mainly Qt based):
https://ubports.com/
Repository and app store for Open Source apps (mainly Java apps):
https://f-droid.org/en/about/
CrystaX NDK provides and alternative to Google's NDK:
https://www.crystax.net/android/ndk

If you know of other Open Source C/C++ software for Android, please advise and I'll add it to the list.


Here are a couple of interesting articles on Android. The first is a list of alternatives to Google's online app store for Android:
https://android.izzysoft.de/articles/named/android_markets_safe_to_use
The next article is about how to make Android a little more Open Source friendly by stripping it of some of the more proprietary apps:
https://android.izzysoft.de/articles/named/android-without-google-5

Another site with information on removing proprietary libraries from Android devices:
https://microg.org/

I've been looking for useful, efficient, user-friendly alternatives to build tools like GNU autotools and cmake. I've even created lists of build tool alternatives at various wikis and sites related to programming and compilers. If there's interest, I can post some of that information here along with pros and cons of various tools. I think, during my searches, I've found some good alternatives for my own projects and to use with my own build script generator.

If you're looking for build tools for your own projects, you may want to try the following tools. I'm also doing some active development and patching to some of the tools and would be interested in comparing notes with others on ways to use and improve them (see below for details).

GNU autotools is probably the most popular build system for most C/C++ programs. So, what's wrong with it? Just to build a C program, you need two interpreters (m4 and Perl). You also need autoconf, automake and make. The input to these programs is not necessarily intuitive to a C programmer. Many C programs, especially those using Qt make use of cmake which has less dependencies, but I've also found it less than intuitive. What if you want to build a system from scratch. You can get make to build without any other build tools. I've done it. From there, you can work to build the rest of the gnu autotools toolchain. To build cmake, you need to bootstrap the build using another instance of cmake. So where do you get the original build of cmake for the system? There is a way to build cmake with gnu autotools, but I've found it rather buggy.

After looking through several make alternatives, I really have not found a good replacement for it. The syntax takes some getting used to, but I've been able to find ways to get it do whatever I need it to do. There are situations where make is very inefficient, but there are work-arounds. Efficiency really depends on how well you craft your makefiles. I attempted to find some alternatives to the GNU version of make. BSD make has very different syntax, so only the simplest make scripts work with both tools. I find GNU make used more often than BSD make for building Open Source projects and it has features that were never added to BSD make. There's a Perl implementation of make, but that requires a Perl interpreter. My main issue with GNU make is that it is only supported on certain platforms. I sent in a bug report about GNU make not working properly on native Windows and I even sent in a patch. The developers were not interested in supporting native Windows. They thought it was enough that there were versions that worked with Cygwin and msys. Unfortunately, I've yet to find an alternative to make that handles the GNU makefile sysntax and doesn't require installation of an interpreter.

I've decided that until I can find anything better, I will continue to use GNU make. Since it is Free Software, I can modify the code to work on other systems that GNU make developers don't care to support. I can distribute the modified version if I distribute the source code. So, I use a modified version of GNU make that fixes platform specific bugs that I've encountered.

After searching through many alternatives, I've found a wonderful replacement to configure/autoconf. It's also more compact and I find it more intuitive than cmake. It's called CDetect. It's written in C and is comprised of only 3 files. The project is no longer actively developed. However, I've been making several modifications of my own to get it to suit my projects' needs. I've implemented some of the items on the original developers To Do lists. I'm still making modifications as I find features that are lacking, but it makes a useful replacement to configure. I've converted some of the Open Source projects I build from source regularly to use CDetect and custom makefiles instead of their build systems. If you're building from source, such as with a Linux from Scratch system, using CDetect means you don't need Perl, and several other programs installed just to build a C/C++ program.

Freedesktop.org advocates the use of pkg-config. It's used by many GNU projects as well. While I originally thought it was yet another complication when building from source, I've found pkg-config rather useful in simplifying build scripts. You don't have to worry about finding the right library, pkg-config can tell you where to find it. If you're cross-compiling, you can get have two sets of directories with pkg-config information, one for cross-compiled libraries and one for regular libraries. Change the path in an environment variable and your build script knows where to find the appropriate libraries. What I really didn't like about pkg-config was the complexity of the program and that it required a circular dependency with glib. I don't even want glib on my system at this point. Luckily, there is an alternative with friendly licensing called pkgconf. It's a drop in replacement for pkg-config. It's very helpful in finding where the right libraries are on a system. I've gone from never using pkg-config to use pkgconf in almost all my build scripts.

So, between CDetect, pkgconf and make, I now have all the tools I need to use with my build system in order to build the Open Source programs and libraries I use most in an automated fashion. The tools are all written in C, so they require no special interpreters or other languages just to build them.

If you'd like to try out CDetect with my patches or see some of the build scripts I'm using with these tools, check out the archive link on my LM BLD system page:
http://www.distasis.com/cpp/lmbld.htm

I've added several features to my patched version of CDetect. Check the notes.txt file for details. I'm currently making some new modifications and would love input from other developers/users. If you'd like to make suggestions or compare notes, please contact me through the CppDesign mailing list or my web site:
http://www.distasis.com/connect.htm

I'm working on several projects. One of my goals is to be able to port any of the SDL 1.2.x programs I use so they'll work with SDL 1.2.15 or with SDL 2.x. So far, I've added SDL 2 support to PDCurses. I believe some or all of those patches made it back into the official version. Other programs I've added SDL2 support for include bard, picaxo, sfontview, unifontview, perigee, SDL_Draw, pong, drac, yahtzee. More are in the works including Tuxmath. Bard is a lightweight epub reader with text to speech support. Picaxo is a lightweight graphics viewer. Sfontview is a lightweight TrueType font viewer. Unifontview is a font viewer that shows a font's entire character set including Unicode characters supported. Perigee is a graphics slideshow program. SDL_Draw is a graphics library for simple line drawing with SDL. I'm currently using it with wavetools to do the line drawing for a lightweight wave file viewer. The wave file viewer also builds with SDL 1.2.x or SDL 2.x.

Code/patches for many of the modifications I've made are available from a link at:
http://www.distasis.com/cpp/patches.htm
I'll be adding more modifications to various projects over time. Feel free to write if you're interesting in discussing a particular SDL 2 conversion further.