Android support

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Android support

François Perrad
Hi,

Lua 5.2.4 could be cross-compiled without patching the sources, just
with some options `-D` in the compiler command line; even if I prefer
patching src/luaconf.h, like that:
+#if defined(__ANDROID__)
+#define getlocaledecpoint()    ('.')
+#define LUA_USE_POSIX
+#define LUA_USE_DLOPEN        /* needs an extra library: -ldl */
+#define LUA_USE_LONGLONG    /* assume support for long long */
+#endif

Lua 5.3.3 requires some patches.
The implementation of strtod() in the Android Bionic C library doesn't
handle the hex format.
So, we must define LUA_USE_C89.
Currently, LUA_USE_C89 implies LUA_USE_C89.
LUA_C89_NUMBERS gives sizeof(lua_Number)==8 and sizeof(lua_Integer)==4
which is a bad mix between LUA_32BITS (both at 4) and the "standard"
(both at 8). And the cross-compiler supports 'long long', so we don't
need LUA_C89_NUMBERS.

I write 2 variants of a patch of luaconf.h, the second removes the
dependency between LUA_USE_C89 and LUA_USE_C89.

A 3rd patch allows to cross compile from the command line `make android`.

And the last patch fixes an issue detected by the official test suite.
The implementation of mkstemp() in Bionic is dummy, so fallback to
tmpnam().

The implementation of setlocale() seems also dummy, but I have no patch.

François

Note: The issue with strtod() was detected here :
https://github.com/fperrad/lua-MessagePack/pull/21

0001-v1-luaconf-android-support.patch (1018 bytes) Download Attachment
0001-v2-luaconf-android-support.patch (922 bytes) Download Attachment
0002-Makefile-android-cross-compilation.patch (2K) Download Attachment
0003-fix-os.tmpname.patch (504 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Android support

Roberto Ierusalimschy
> Lua 5.3.3 requires some patches.
> The implementation of strtod() in the Android Bionic C library doesn't
> handle the hex format.
> So, we must define LUA_USE_C89.
> [...]

If the only problem with C99 is strtod, wouldn't be easier to simply
undefine 'lua_strx2number' for Android (instead of defining LUA_USE_C89)?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Android support

François Perrad
2016-11-03 16:37 GMT+01:00 Roberto Ierusalimschy <[hidden email]>:

>> Lua 5.3.3 requires some patches.
>> The implementation of strtod() in the Android Bionic C library doesn't
>> handle the hex format.
>> So, we must define LUA_USE_C89.
>> [...]
>
> If the only problem with C99 is strtod, wouldn't be easier to simply
> undefine 'lua_strx2number' for Android (instead of defining LUA_USE_C89)?
>
> -- Roberto
>

Android is not a developper friendly target.
For example, log2() is available only since ABI 18.
So, using LUA_USE_C89 is a conservative choice (not an optimal
choice), like with Windows.
On Android, like on Windows, we don't need LUA_C89_NUMBERS.
I think that LUA_USE_C89 + LUA_C89_NUMBERS is only for very old
compiler/toolchain.
It is the reason for my variant 2, where the dependency between
LUA_USE_C89 and LUA_USE_C89 is removed.

François

Reply | Threaded
Open this post in threaded view
|

Re: Android support

François Perrad
2016-11-03 18:30 GMT+01:00 François Perrad <[hidden email]>:

> 2016-11-03 16:37 GMT+01:00 Roberto Ierusalimschy <[hidden email]>:
>>> Lua 5.3.3 requires some patches.
>>> The implementation of strtod() in the Android Bionic C library doesn't
>>> handle the hex format.
>>> So, we must define LUA_USE_C89.
>>> [...]
>>
>> If the only problem with C99 is strtod, wouldn't be easier to simply
>> undefine 'lua_strx2number' for Android (instead of defining LUA_USE_C89)?
>>
>> -- Roberto
>>
>
> Android is not a developper friendly target.
> For example, log2() is available only since ABI 18.
> So, using LUA_USE_C89 is a conservative choice (not an optimal
> choice), like with Windows.
> On Android, like on Windows, we don't need LUA_C89_NUMBERS.
> I think that LUA_USE_C89 + LUA_C89_NUMBERS is only for very old
> compiler/toolchain.
> It is the reason for my variant 2, where the dependency between
> LUA_USE_C89 and LUA_USE_C89 is removed.
>
> François

In fact, LUA_C89_NUMBERS could be fully removed.
Its behaviour could be emulated from src/Makefile by setting
    MYCFLAGS= -DLUA_INT_TYPE=2 -DLUA_FLOAT_TYPE=2

François

Reply | Threaded
Open this post in threaded view
|

Re: Android support

Pierre Chapuis
Thank you François for bringing this up on the list (the discussion originated from a bug report I sent on one of his libraries [1]).

We have had Lua in production in an Android mobile application with thousands of installs for about a week now. So far the only Android-related changes we have made are just not using log2 and not using LUA_C89_NUMBERS (similar to what François is proposing). We have seen no further Lua-related issues so far. [2]

[1] https://github.com/fperrad/lua-MessagePack/pull/21
[2] https://gist.github.com/catwell/9c2cf1a4f86c68d9a53deeb989c37b62

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: Android support

Marc Balmer
I am late to the game, but I recently started working on an Android app
that includes Lua.  Fortunately I have quite a bit of experience with
the JNI and several (non Android) projects where Lua is called from Java...

Now I wonder how other Android/Lua hackers handle 'require' for modules
written in C/C++.  Do you link your modules with Lua into a single
library or do you create several .so files?  If the latter, how do you
trick Lua into loading the right shared object?

- mb


Reply | Threaded
Open this post in threaded view
|

Re: Android support

Pierre Chapuis
December 25, 2016 4:02 PM, "Marc Balmer" <[hidden email]> wrote:
> I am late to the game, but I recently started working on an Android app
> that includes Lua. Fortunately I have quite a bit of experience with
> the JNI and several (non Android) projects where Lua is called from Java...
>
> Now I wonder how other Android/Lua hackers handle 'require' for modules
> written in C/C++. Do you link your modules with Lua into a single
> library or do you create several .so files? If the latter, how do you
> trick Lua into loading the right shared object?

For now I link everything statically.

Reply | Threaded
Open this post in threaded view
|

Re: Android support

Thomas Fletcher
In reply to this post by Marc Balmer

On Dec 25, 2016 7:02 AM, "Marc Balmer" <[hidden email]> wrote:
>
> I am late to the game, but I recently started working on an Android app
> that includes Lua.  Fortunately I have quite a bit of experience with
> the JNI and several (non Android) projects where Lua is called from Java...
>
> Now I wonder how other Android/Lua hackers handle 'require' for modules
> written in C/C++.  Do you link your modules with Lua into a single
> library or do you create several .so files?  If the latter, how do you
> trick Lua into loading the right shared object?

With Storyboard we give the user the ability to list their binary modules and then preload them in the main android application by dlopening the files so that later when we retry within a secondary or tertiary module it succeeds.

Thomas

Reply | Threaded
Open this post in threaded view
|

Re: Android support

Marc Balmer


Am 25.12.16 um 20:02 schrieb Thomas Fletcher:

> On Dec 25, 2016 7:02 AM, "Marc Balmer" <[hidden email]
> <mailto:[hidden email]>> wrote:
>>
>> I am late to the game, but I recently started working on an Android app
>> that includes Lua.  Fortunately I have quite a bit of experience with
>> the JNI and several (non Android) projects where Lua is called from
> Java...
>>
>> Now I wonder how other Android/Lua hackers handle 'require' for modules
>> written in C/C++.  Do you link your modules with Lua into a single
>> library or do you create several .so files?  If the latter, how do you
>> trick Lua into loading the right shared object?
>
> With Storyboard we give the user the ability to list their binary
> modules and then preload them in the main android application by
> dlopening the files so that later when we retry within a secondary or
> tertiary module it succeeds.

Thanks so far.  So I am now able to detect the CPU architecture and ABI
using C preprocessor defines and in theory I can now adjust the
LUA_CPATH_DEFAULT definition in luaconf.h.  But is the APK file actually
unpacked on the Android device's file system?  I.e. can I just adjust
the CPATH and then use dlopen() to load the module?  Or do I have unzip
the APK first?

I was also considering writing a separate loader that calls
System.loadLibrary() via the JNI, but then that assumes as "lib" prefix
on the shared library, which we omit for Lua modules (we often have a C
library called e.g. libfoobar.so _and_ a Lua binding to it called
foobar.so).

Reply | Threaded
Open this post in threaded view
|

Re: Android support

Eric Wing
On 12/25/16, Marc Balmer <[hidden email]> wrote:

>
>
> Am 25.12.16 um 20:02 schrieb Thomas Fletcher:
>
>> On Dec 25, 2016 7:02 AM, "Marc Balmer" <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>>
>>> I am late to the game, but I recently started working on an Android app
>>> that includes Lua.  Fortunately I have quite a bit of experience with
>>> the JNI and several (non Android) projects where Lua is called from
>> Java...
>>>
>>> Now I wonder how other Android/Lua hackers handle 'require' for modules
>>> written in C/C++.  Do you link your modules with Lua into a single
>>> library or do you create several .so files?  If the latter, how do you
>>> trick Lua into loading the right shared object?
>>
>> With Storyboard we give the user the ability to list their binary
>> modules and then preload them in the main android application by
>> dlopening the files so that later when we retry within a secondary or
>> tertiary module it succeeds.
>
> Thanks so far.  So I am now able to detect the CPU architecture and ABI
> using C preprocessor defines and in theory I can now adjust the
> LUA_CPATH_DEFAULT definition in luaconf.h.  But is the APK file actually
> unpacked on the Android device's file system?  I.e. can I just adjust
> the CPATH and then use dlopen() to load the module?  Or do I have unzip
> the APK first?
>
> I was also considering writing a separate loader that calls
> System.loadLibrary() via the JNI, but then that assumes as "lib" prefix
> on the shared library, which we omit for Lua modules (we often have a C
> library called e.g. libfoobar.so _and_ a Lua binding to it called
> foobar.so).
>
>

I try to preserve the usual Lua semantics for Android which means
building dynamic libraries. So as you identified, I always use the lib
prefex on Android. But this isn't just for System.loadLibrary(), but
affects what Android does when it encounters your .apk. Android
automatically extracts out the lib*.so files into a special directory
so it is possible to use them. It ignores everything else. CPATH alone
wouldn't help you since the files are not directly on the filesystem,
but archived inside the APK.


I had a slide about this in my talk, "Tales of a Lua engine embedder
thrown into the JavaScript world" at the Lua Workshop 2016. It's
around slide #34 at about the 10 minute mark.
https://www.lua.org/wshop16.html

I use this for BlurrrSDK. I also made changes to make normal Lua
semantics work on iOS with its static linking. (Mentioned in the
following slide.)

-Eric

Reply | Threaded
Open this post in threaded view
|

Re: Android support

Marc Balmer


Am 26.12.16 um 01:34 schrieb Eric Wing:

> On 12/25/16, Marc Balmer <[hidden email]> wrote:
>>
>>
>> Am 25.12.16 um 20:02 schrieb Thomas Fletcher:
>>
>>> On Dec 25, 2016 7:02 AM, "Marc Balmer" <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>>
>>>> I am late to the game, but I recently started working on an Android app
>>>> that includes Lua.  Fortunately I have quite a bit of experience with
>>>> the JNI and several (non Android) projects where Lua is called from
>>> Java...
>>>>
>>>> Now I wonder how other Android/Lua hackers handle 'require' for modules
>>>> written in C/C++.  Do you link your modules with Lua into a single
>>>> library or do you create several .so files?  If the latter, how do you
>>>> trick Lua into loading the right shared object?
>>>
>>> With Storyboard we give the user the ability to list their binary
>>> modules and then preload them in the main android application by
>>> dlopening the files so that later when we retry within a secondary or
>>> tertiary module it succeeds.
>>
>> Thanks so far.  So I am now able to detect the CPU architecture and ABI
>> using C preprocessor defines and in theory I can now adjust the
>> LUA_CPATH_DEFAULT definition in luaconf.h.  But is the APK file actually
>> unpacked on the Android device's file system?  I.e. can I just adjust
>> the CPATH and then use dlopen() to load the module?  Or do I have unzip
>> the APK first?
>>
>> I was also considering writing a separate loader that calls
>> System.loadLibrary() via the JNI, but then that assumes as "lib" prefix
>> on the shared library, which we omit for Lua modules (we often have a C
>> library called e.g. libfoobar.so _and_ a Lua binding to it called
>> foobar.so).
>>
>>
>
> I try to preserve the usual Lua semantics for Android which means
> building dynamic libraries. So as you identified, I always use the lib
> prefex on Android. But this isn't just for System.loadLibrary(), but
> affects what Android does when it encounters your .apk. Android
> automatically extracts out the lib*.so files into a special directory
> so it is possible to use them. It ignores everything else. CPATH alone
> wouldn't help you since the files are not directly on the filesystem,
> but archived inside the APK.

So it _only_ extracts lib*.so files, and not *.so, right?  In that case
I will have to prefix my Lua modules with 'lib' which is no big deal.

Do you know the path where it extracts lib*.so files to?  If that is
known and constant, it could be possible to doctor CPATH so that require
loads those using dlopen().  Certainly something I want to give a try.


> I had a slide about this in my talk, "Tales of a Lua engine embedder
> thrown into the JavaScript world" at the Lua Workshop 2016. It's
> around slide #34 at about the 10 minute mark.
> https://www.lua.org/wshop16.html

Thanks for the pointer, I will watch that talk this morning
(unfortunately I was not able to attend the workshop this year).

> I use this for BlurrrSDK. I also made changes to make normal Lua
> semantics work on iOS with its static linking. (Mentioned in the
> following slide.)

Her we work on mobile POS and visitor management system.  The goal is to
have an open platform based on Honeywell devices where applications
(written in Lua) can be loaded at runtime.

- mb


Reply | Threaded
Open this post in threaded view
|

Re: Android support

Eric Wing
On 12/26/16, Marc Balmer <[hidden email]> wrote:

>
>
> Am 26.12.16 um 01:34 schrieb Eric Wing:
>> On 12/25/16, Marc Balmer <[hidden email]> wrote:
>>>
>>>
>>> Am 25.12.16 um 20:02 schrieb Thomas Fletcher:
>>>
>>>> On Dec 25, 2016 7:02 AM, "Marc Balmer" <[hidden email]
>>>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>> I am late to the game, but I recently started working on an Android
>>>>> app
>>>>> that includes Lua.  Fortunately I have quite a bit of experience with
>>>>> the JNI and several (non Android) projects where Lua is called from
>>>> Java...
>>>>>
>>>>> Now I wonder how other Android/Lua hackers handle 'require' for
>>>>> modules
>>>>> written in C/C++.  Do you link your modules with Lua into a single
>>>>> library or do you create several .so files?  If the latter, how do you
>>>>> trick Lua into loading the right shared object?
>>>>
>>>> With Storyboard we give the user the ability to list their binary
>>>> modules and then preload them in the main android application by
>>>> dlopening the files so that later when we retry within a secondary or
>>>> tertiary module it succeeds.
>>>
>>> Thanks so far.  So I am now able to detect the CPU architecture and ABI
>>> using C preprocessor defines and in theory I can now adjust the
>>> LUA_CPATH_DEFAULT definition in luaconf.h.  But is the APK file actually
>>> unpacked on the Android device's file system?  I.e. can I just adjust
>>> the CPATH and then use dlopen() to load the module?  Or do I have unzip
>>> the APK first?
>>>
>>> I was also considering writing a separate loader that calls
>>> System.loadLibrary() via the JNI, but then that assumes as "lib" prefix
>>> on the shared library, which we omit for Lua modules (we often have a C
>>> library called e.g. libfoobar.so _and_ a Lua binding to it called
>>> foobar.so).
>>>
>>>
>>
>> I try to preserve the usual Lua semantics for Android which means
>> building dynamic libraries. So as you identified, I always use the lib
>> prefex on Android. But this isn't just for System.loadLibrary(), but
>> affects what Android does when it encounters your .apk. Android
>> automatically extracts out the lib*.so files into a special directory
>> so it is possible to use them. It ignores everything else. CPATH alone
>> wouldn't help you since the files are not directly on the filesystem,
>> but archived inside the APK.
>
> So it _only_ extracts lib*.so files, and not *.so, right?  In that case
> I will have to prefix my Lua modules with 'lib' which is no big deal.

Yes, you need lib*.so.
But pay extra attention to the LuaSocket part in that part of the
talk. There are no subdirectories allowed for libraries so you have to
do more work for Lua modules that follow the LuaSocket layout
convention.


> Do you know the path where it extracts lib*.so files to?  If that is
> known and constant, it could be possible to doctor CPATH so that require
> loads those using dlopen().  Certainly something I want to give a try.

It's in the preceding slide (33?). However, I forgot to say that you
should never actually rely on that path. That is a private
implementation detail and Google has refused to give us a public API
for the path. Google is also pretty flippant about breaking
existing/shipping binaries already on the store for those who use the
NDK. For example, I've heard a surprising number of people were broken
by the recent changes in the rules for SONAME.

-Eric

Reply | Threaded
Open this post in threaded view
|

Re: Android support

Marc Balmer
In reply to this post by Marc Balmer


Am 26.12.16 um 10:04 schrieb Marc Balmer:
[...]

>> I try to preserve the usual Lua semantics for Android which means
>> building dynamic libraries. So as you identified, I always use the lib
>> prefex on Android. But this isn't just for System.loadLibrary(), but
>> affects what Android does when it encounters your .apk. Android
>> automatically extracts out the lib*.so files into a special directory
>> so it is possible to use them. It ignores everything else. CPATH alone
>> wouldn't help you since the files are not directly on the filesystem,
>> but archived inside the APK.
>
> So it _only_ extracts lib*.so files, and not *.so, right?  In that case
> I will have to prefix my Lua modules with 'lib' which is no big deal.
>
> Do you know the path where it extracts lib*.so files to?  If that is
> known and constant, it could be possible to doctor CPATH so that require
> loads those using dlopen().  Certainly something I want to give a try.

I found out (by googling and a bit of trial and error) that lib*.so
files get extracted to /data/data/<app id>/lib/.

So setting the LUA_CPATH_DEFAULT actually works, e.g. my app id is
ch.msys.lua, so I have the following in my luaconf.h file:

#undef LUA_CPATH_DEFAULT
#define LUA_CPATH_DEFAULT "/data/data/ch.msys.lua/lib/lib?.so"

With this, I can now 'require' any dynamically linked Lua module that I
put in to my software.

Reply | Threaded
Open this post in threaded view
|

Re: Android support

Marc Balmer
In reply to this post by Eric Wing


Am 26.12.16 um 10:29 schrieb Eric Wing:

> On 12/26/16, Marc Balmer <[hidden email]> wrote:
>>
>>
>> Am 26.12.16 um 01:34 schrieb Eric Wing:
>>> On 12/25/16, Marc Balmer <[hidden email]> wrote:
>>>>
>>>>
>>>> Am 25.12.16 um 20:02 schrieb Thomas Fletcher:
>>>>
>>>>> On Dec 25, 2016 7:02 AM, "Marc Balmer" <[hidden email]
>>>>> <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>> I am late to the game, but I recently started working on an Android
>>>>>> app
>>>>>> that includes Lua.  Fortunately I have quite a bit of experience with
>>>>>> the JNI and several (non Android) projects where Lua is called from
>>>>> Java...
>>>>>>
>>>>>> Now I wonder how other Android/Lua hackers handle 'require' for
>>>>>> modules
>>>>>> written in C/C++.  Do you link your modules with Lua into a single
>>>>>> library or do you create several .so files?  If the latter, how do you
>>>>>> trick Lua into loading the right shared object?
>>>>>
>>>>> With Storyboard we give the user the ability to list their binary
>>>>> modules and then preload them in the main android application by
>>>>> dlopening the files so that later when we retry within a secondary or
>>>>> tertiary module it succeeds.
>>>>
>>>> Thanks so far.  So I am now able to detect the CPU architecture and ABI
>>>> using C preprocessor defines and in theory I can now adjust the
>>>> LUA_CPATH_DEFAULT definition in luaconf.h.  But is the APK file actually
>>>> unpacked on the Android device's file system?  I.e. can I just adjust
>>>> the CPATH and then use dlopen() to load the module?  Or do I have unzip
>>>> the APK first?
>>>>
>>>> I was also considering writing a separate loader that calls
>>>> System.loadLibrary() via the JNI, but then that assumes as "lib" prefix
>>>> on the shared library, which we omit for Lua modules (we often have a C
>>>> library called e.g. libfoobar.so _and_ a Lua binding to it called
>>>> foobar.so).
>>>>
>>>>
>>>
>>> I try to preserve the usual Lua semantics for Android which means
>>> building dynamic libraries. So as you identified, I always use the lib
>>> prefex on Android. But this isn't just for System.loadLibrary(), but
>>> affects what Android does when it encounters your .apk. Android
>>> automatically extracts out the lib*.so files into a special directory
>>> so it is possible to use them. It ignores everything else. CPATH alone
>>> wouldn't help you since the files are not directly on the filesystem,
>>> but archived inside the APK.
>>
>> So it _only_ extracts lib*.so files, and not *.so, right?  In that case
>> I will have to prefix my Lua modules with 'lib' which is no big deal.
>
> Yes, you need lib*.so.
> But pay extra attention to the LuaSocket part in that part of the
> talk. There are no subdirectories allowed for libraries so you have to
> do more work for Lua modules that follow the LuaSocket layout
> convention.

Actually we have exactly this "flat" scheme for our modules, no subdirs
luckily (and we don't use LuaSocket, we have our own 'net' module).

>> Do you know the path where it extracts lib*.so files to?  If that is
>> known and constant, it could be possible to doctor CPATH so that require
>> loads those using dlopen().  Certainly something I want to give a try.
>
> It's in the preceding slide (33?). However, I forgot to say that you
> should never actually rely on that path. That is a private
> implementation detail and Google has refused to give us a public API
> for the path. Google is also pretty flippant about breaking
> existing/shipping binaries already on the store for those who use the
> NDK. For example, I've heard a surprising number of people were broken
> by the recent changes in the rules for SONAME.

So we should probably use a custom loader that uses the JNI to call
System.loadLibrary() to be safe.  That should be quite easy to do.


Reply | Threaded
Open this post in threaded view
|

Re: Android support

Marc Balmer
In reply to this post by Eric Wing


Am 26.12.16 um 10:29 schrieb Eric Wing:

>> Do you know the path where it extracts lib*.so files to?  If that is
>> known and constant, it could be possible to doctor CPATH so that require
>> loads those using dlopen().  Certainly something I want to give a try.
>
> It's in the preceding slide (33?). However, I forgot to say that you
> should never actually rely on that path. That is a private
> implementation detail and Google has refused to give us a public API
> for the path. Google is also pretty flippant about breaking
> existing/shipping binaries already on the store for those who use the
> NDK. For example, I've heard a surprising number of people were broken
> by the recent changes in the rules for SONAME.

Oh, I forgot to mention that I target two specific devices, the
Honexwell Dolphin 75e and CT-50, and I am in close contact with
Honeywell, so if they changed that location, I would know ;)


Reply | Threaded
Open this post in threaded view
|

Re: Android support

Marc Balmer
In reply to this post by Eric Wing

> It's in the preceding slide (33?). However, I forgot to say that you
> should never actually rely on that path. That is a private
> implementation detail and Google has refused to give us a public API
> for the path. Google is also pretty flippant about breaking
> existing/shipping binaries already on the store for those who use the
> NDK. For example, I've heard a surprising number of people were broken
> by the recent changes in the rules for SONAME.
>
>
So I just read your slides, quite depressing to hear that Google puts so
little effort into the NDK.
For the record, there is actually a Java function you can use to query
the System.loadLibrary() path, but for now I go with hardcoding
/data/data/packagename/lib.  Works for me so far.

Thanks for your help!

- mb


Reply | Threaded
Open this post in threaded view
|

Re: Android support

Marc Balmer
In reply to this post by Marc Balmer
So here's a next step towards Lua in Android:

I can now add Lua to an Android project in Android Studio and also
provide almost all of our modules that are written in C to it,  that
includes stuff like protocols for credit card terminals and such.  I am
currently trying to port openssl, cURL, and, libpq to Android, to make
things complete.  Lua itself and the modules are shared libraries, only
loaded when 'require'd.

Since an Android program is inevitably started by calling some piece of
Java software, I wrote a Java native library wich provides the Lua API
to Java.  That way I can use the Lua API directly from Java and it
becomes super easy to orchestrate Lua from a Java application.

The next step will likely be a Lua module that provides a JNI binding,
so that calling Java code from Lua becomes easy as well.

Reply | Threaded
Open this post in threaded view
|

Re: Android support

steve donovan
On Tue, Dec 27, 2016 at 3:10 PM, Marc Balmer <[hidden email]> wrote:
> The next step will likely be a Lua module that provides a JNI binding,
> so that calling Java code from Lua becomes easy as well.

You need look no further than LuaJava, since it's done that tricky JNI
stuff for you, plus reflection-based interfaces. It was a revelation
how straightforward Android programming became (I maintain (sort of) a
fork of Michel Kottman's AndroLua which explored this)

Reply | Threaded
Open this post in threaded view
|

Re: Android support

Marc Balmer


Am 27.12.16 um 14:53 schrieb steve donovan:
> On Tue, Dec 27, 2016 at 3:10 PM, Marc Balmer <[hidden email]> wrote:
>> The next step will likely be a Lua module that provides a JNI binding,
>> so that calling Java code from Lua becomes easy as well.
> You need look no further than LuaJava, since it's done that tricky JNI
> stuff for you, plus reflection-based interfaces. It was a revelation
> how straightforward Android programming became (I maintain (sort of) a
> fork of Michel Kottman's AndroLua which explored this)
>
I have seen the AndroLua stuff and I will certaily steal there ;) Is
yours more evolved and available as well?  I might as well steal from you ;P

Thanks for the pointer!

- mb


Reply | Threaded
Open this post in threaded view
|

Re: Android support

steve donovan
On Tue, Dec 27, 2016 at 4:54 PM, Marc Balmer <[hidden email]> wrote:
> Thanks for the pointer!

Steal away ;)  Picasso once said, "Good artists copy and great artists
steal".  I _think_ he meant that a great artist sees the basic
underlying principle of an artwork, and takes that, but it's hard to
tell with Picasso.

12