Re: Android support

[Marc Balmer <marc@...>]

Am 26.12.16 um 01:34 schrieb Eric Wing:
> On 12/25/16, Marc Balmer <marc@msys.ch> wrote:
>>
>>
>> Am 25.12.16 um 20:02 schrieb Thomas Fletcher:
>>
>>> On Dec 25, 2016 7:02 AM, "Marc Balmer" <marc@msys.ch
>>> <mailto:marc@msys.ch>> 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