I’m interested in porting some of the Open Source C/C++ applications I use to Android. I’ve been reading up on various tutorials. I’m investigating using the standalone toolchain to build the programs from source code.
Have some questions (below) about the process of putting together an Android package using the NDK and ported Open Source code. Would appreciate development tips or pointers to other relevant documentation or forums about building C/C++ applications for Android. Thanks.
What API version do F-Droid developers typically target? Our local Android meetup group recommended using an old enough API that it would support the majority of users. However, I read a few articles that said Google Play store is going to start requiring more up-to-date APIs. What do other F-Droid developers recommend?
For those that are using C/C++ code, what platforms do you typically target (for example: arm-linux-androideabi, i686-linux-android, etc.)?
I would guess a lot of the standard C/C++ libraries (such as zlib, libpng, freetype, SDL2, etc.) used in many Open Source projects would require similar patches to build and work properly on Android. Is there any place (or places) those patches are being shared if they don’t make it back into the upstream projects’ source code?
In NDK you have to handle your stuff well, i.e. you need to make the build for a dedicated instruction set (or several builds) arm v7, x86 but also you need to account for different CPU features like NEON being present or not.
I once ported native multimedia code to android platform. A lot of testing is needed. In low level you will find much more annoying bugs than at Java level. For some of the platforms with such quirks I was able to get the kernel source and verify the culprit otherwise it was just frustrating monkey development - just scratching your head and trying to do any workaround to make it work. The final product did not work everywhere, some devices, mostly cheap Chinese models, were not well supported. It was at the times of Android 4.4, where I had to support Android 2.3 and up, so hope nowadays the devices are better.
Regarding Android API levels in general, unless you wish to support something old I would say Android 4.0 is the lowest to think about. Recently I built one app for API 7 and I suddenly discovered that using the newest gradle 3 makes the final build supported from API 10 (my project settings were silently uplifted during build) so I stay with gradle 2.
Thanks for the replies and tips. The link to the Termux project and the packages they’ve built looks really interesting. I wonder what toolchain they’re using to build some of those packages. I followed the instructions ( Standalone toolchains (obsolete) | Android NDK | Android Developers ) to create standalone toolchains for arm and x86, so both compilers are 32 bit. I’m hitting several issues where the 32 bit toolchains don’t fully support file operations for large files and having to patch for it. Don’t notice any similar patches in the Termux project’s packages. Also couldn’t find some of the packages I just finished creating build scripts for such as bzip2 and giflib. Does look like a good source of information though. I wonder if they’d be interested in some of my build scripts/patches for libraries/utilities they don’t have listed.
Is there a good person or place to contact regarding new packages? I noticed the Community page at the Termux wiki lists a Google+ group, a mailing list and IRC/gitter for communications. Thanks.
Short answer: use the NDK with the aforementioned precautions and avoid relying on it for “mission critical” stuff, because it’s poorly written from a security standpoint (run a static code analyzer to get a feel). For the latter, embed it in your custom system build and call it as a library (become Google). With this state of affairs, Google has an “open ecosystem” where it’s sure to always keep the Lion’s cut (think of payment apps or the Chrome browser, which has its own non-NDK SSL library, not made a available to other sofware). The next Android version is even disabling the use of “undocumented API calls”, thereby officializing and enforcing further this schoolbook example of digital divide by design. This is why we launched CEuniX (CEuniX.world) as a project to make a secure mobile FOSS OS without such limitations, integrating state of the art cryptography, also modulable to your heart’s content (important in these times of crypto-everything, i.e. SHA2’s not eternal).
Thanks for the interesting comments, sti. Was not planning on using it for anything mission critical. Wouldn’t it be possible to use LibreSSL or other SSL library of choice compiled using the NDK and linked into a program? Was planning on testing this out. Also, I’ve seen projects like Crystax ( https://www.crystax.net/ ) that replace the C library with their own. It would be interesting to attempt to use a C library like musl in place of Bionic. I’m not planning on building anything for use with Google Play. I’m more interested in side-loading or hopefully making something available through F-Droid. So, there shouldn’t be any non-technical restrictions on what code I build or work with. I’ve been reading a little about Replicant and their hopes to create a more secure Android distribution. This is the first I’ve heard of CEuniX though. Sounds like an interesting project. Wish you the best of luck with it.