LiveCode Forums

I am confused about the state of affairs regarding Android Externals. Looks like some folks have integrated Java as the external, and then the merg folks have some externals for Android, but I don't really see anything that says, "As of version x.y.z, you can write C/C++ externals using these header files, libraries, etc." Is there such a thing for Android? Is it just for Java? I have a desktop external (Win + Linux) I would like to get working on Android.

I agree. Honestly I can't fathom why C/C++ externals wouldn't work on every platform supported by livecode. I really want to implement libtoxcore (https://github.com/irungentoo/ProjectTox-Core) in to an external so I can develop a cross platform Tox client. Sadly, it would appear that externals are not so easy to do.

I would be happy with "not so easy to do". At least that means it is possible!

The current state of LC Android externals has forced me to go native Android for a couple of projects.
Hopefully things will improve in the near future.

Paul

Looks like I should have looked around more before giving up. Monte Goulding on http://livecode.com/blog/2013/ says

One of the first things I noticed was it is quite easy to use the old externals SDK on iOS and Android for C or C++ externals. That’s how all of RunRev’s externals work cross platform and how mergJSON and mergMarkdown went cross platform. The problems start though when you want to access Android’s Java API.

For the folks that have read this, I'll give an update after I try it.

"There is no try, only do." --paraphrased from everyone's favorite small Jedi.

WinstonJenks wrote:Looks like I should have looked around more before giving up. Monte Goulding on http://livecode.com/blog/2013/ says

One of the first things I noticed was it is quite easy to use the old externals SDK on iOS and Android for C or C++ externals. That’s how all of RunRev’s externals work cross platform and how mergJSON and mergMarkdown went cross platform. The problems start though when you want to access Android’s Java API.

For the folks that have read this, I'll give an update after I try it.

"There is no try, only do." --paraphrased from everyone's favorite small Jedi.

Does that mean someone could port libtoxcore to a Livecode external? I know C, but only for the purposes of coding a micro controller. When it comes to higher level stuff my knowledge skips right over most OOP stuff (I know a little but not a lot) and lands right here at LiveCode as well as AppleScript and JavaScript/CSS/HTML

Getting closer... Does anyone know where the files show up that you put in the "CopyFiles" pane of the Standalone build settings. After the program is installed. cannot find where those files exist. This could be the problem now why the .so doea not load--because nothing knows where those files are..!

It also seems like some C++ library (stlport_shared.so, for instance) may need to be loaded before the external.so is loaded (if the external.so) uses things from the STL. Anybody have an idea about that? There was a note in the Android NDK, that said to put some Java code in the app like:

static {
System.loadlibrary("stlport_shared.so");
}

apparently that was an idea to get the STL loaded right up front before anything else starts. Any way to drop that into the Adroid standalone?

Anything in the copy files pane is placed into the same folder with the standalone engine in the apk.

Does that

Anything in the copy files pane is placed into the same folder with the standalone engine

magically happen at run-time (or install-time) when the .apk is unpacked? If I unzip the .apk file, then I see that the things I add in the Copy Files pane are placed in /assets folder inside the .apk file. The standalone engine is placed in /libs/armeabi inside the .apk. And if I just assume that the .so containing the external code is in the default folder, then the external does not load. Perhaps this is because the defaultfolder when the app runs is "/" (there could be some magic chroot going on--I am not really up on the Android run-time environment). I was toying with unpacking the .apk, then re-packing it, shoving the required .so files in the same location as the revolution runtime library, but I have not looked into doing that yet--and I am not even sure that would work.

This is all happening with version 6.5.2. I know that the external library is fine, because if I put it at /tmp/libmylib.so and set the externals of the stack to "/tmp/libmylib.so" so it loads from that specific directory, it works just fine. But I have not been able to find the right amount of bat wing or eye of newt that gets the external loaded in any other way that does not require heroic efforts to outwit the file system. I am sure if I knew more, this would be easier. I guess it's time to dig into the Android run-time documentation. Suggestions welcome.

So far, the good news is that I can compile a library that will work as an external using essentially the same mechanism as you would use on the Windows or Linux (assuming you have 32-bit tools ) desktop. Once I get past the deployment issues (and the fact that the default Android runtime library has scantily little support for C++ libraries {#include <exceptions> requires you to define a specific APP_STL, which you then also need to figure out how to load at runtime]), then it looks like this should happen.

Hi Winston,
Appreciate the info in your posts here. Please keep us informed on what you are doing.
As you know, information on Android externals is thin on the ground.

Paul

If I set the standalone settings to include revZip, then sure enough, the librevzip.so makes it into the /lib/armeabi folder of the .apk file. But I do not see how to get my libraries into that location. This might be the last holdup.