Current state of Android externals

Interested adding compiled externals from LiveCode and third parties to your LiveCode projects? This is the place to talk about them.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Post Reply
WinstonJenks
Posts: 36
Joined: Fri Jan 01, 2010 12:11 am

Current state of Android externals

Post by WinstonJenks » Tue Apr 15, 2014 1:20 am

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.

EssoAir
Posts: 52
Joined: Thu Feb 20, 2014 7:53 pm

Re: Current state of Android externals

Post by EssoAir » Tue Apr 15, 2014 2:55 am

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.

WinstonJenks
Posts: 36
Joined: Fri Jan 01, 2010 12:11 am

Re: Current state of Android externals

Post by WinstonJenks » Tue Apr 15, 2014 9:49 pm

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

paul_gr
Posts: 319
Joined: Fri Dec 08, 2006 7:38 pm
Location: Blenheim, New Zealand

Re: Current state of Android externals

Post by paul_gr » Wed Apr 16, 2014 12:20 am

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

WinstonJenks
Posts: 36
Joined: Fri Jan 01, 2010 12:11 am

Re: Current state of Android externals

Post by WinstonJenks » Thu Apr 17, 2014 2:23 am

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.

EssoAir
Posts: 52
Joined: Thu Feb 20, 2014 7:53 pm

Re: Current state of Android externals

Post by EssoAir » Thu Apr 17, 2014 3:03 am

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

WinstonJenks
Posts: 36
Joined: Fri Jan 01, 2010 12:11 am

Re: Current state of Android externals

Post by WinstonJenks » Tue Apr 29, 2014 12:32 pm

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?

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7215
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Current state of Android externals

Post by jacque » Tue Apr 29, 2014 4:54 pm

Anything in the copy files pane is placed into the same folder with the standalone engine in the apk.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

WinstonJenks
Posts: 36
Joined: Fri Jan 01, 2010 12:11 am

Re: Current state of Android externals

Post by WinstonJenks » Tue Apr 29, 2014 7:13 pm

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.

paul_gr
Posts: 319
Joined: Fri Dec 08, 2006 7:38 pm
Location: Blenheim, New Zealand

Re: Current state of Android externals

Post by paul_gr » Tue Apr 29, 2014 10:29 pm

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

WinstonJenks
Posts: 36
Joined: Fri Jan 01, 2010 12:11 am

Re: Current state of Android externals

Post by WinstonJenks » Wed Apr 30, 2014 4:40 am

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.

Post Reply

Return to “Using Externals”