Ok. this has taken alot of investigation and I think Im at a bit of an impass. Theres a couple of ways around the problems for Android, but I can see there being other issues with other extensions that might be built this way.
Firstly, I’ll explain how the sqlite build process works and why.
Normally Defold extensions are built all in a source folder and that is compiled together into your application and that is all that needs to be done. However, there is a problem building sqlite and sqlite amalg.
The code uses old C methodologies and the clang++ compiler does not accept them (usually casting related).
Normally with say gcc, you could disable some of these items and build anyway. However in this case, the extension compiler is using Defold build system which uses clang++ and android19 abi for armv7 and android22 for arm64.
To be able to build the extension, I decided I could build a static library and link it into the extension, thus embedding sqlite3 into the extension. This is what all the lib files are. Various versions of static libraries for use on different platforms. Easy. Solved right?
No sadly. These need to be also built with the same compiler. However, I had to use the clang C compiler (this shouldnt matter, but it might) to build the libraries. This is what the sqlite3-amalg repo in my repositories is for. This builds all the platforms with the correct settings.
Then these libs are copied into the defold-sqlite/libs folder and then the project can be built for whatever platform you need. However, the android extension does not seem to be linking in the static libraries. And creating a separate shared library that is attempted to be called at runtime. From the error logs in logcat, it looks like that these files, because they dont have runtime permission, fail to allow the main app to call and execute them.
Ideally these shared libraries shouldnt even exist. There is an added complication too. Most (if not all) Android devices already have a shared sqlite library installed as part of the OS. And this could be problematic if the shared library is trying to call OS linked libraries (which it shouldnt).
Ways forward:
- It could be possible to setup a Extension build server and then build the extensions exactly as needed, but this is alot of work.
- Modify the sqlite amalg C code to not have errors and build it within the extension build process. This is a huge job. I did look at this last year, and it is not worth it considering the updates that sqlite regularly do.
- Use the Android builtin library and call directly. This is probably the most promising way forward, but it would need a separate build process to do this. In fact, it might be easier to just make an android sqlite specific project. I suspect the IOS version may suffer similar issues.
Having done quite a number of wildly different extensions, generally, I have found ways around problems. This one sadly has been one of the more “blocker” styled ones.
Being able to link libs into the extension should work fine but this is a little more complicated with the C/C++ differential. I have ran into other C libs which do not build well in extensions, so it does seem to be a limiting factor and it has me wondering about alternatives.
Anyway, to tc. Sorry mate. I think your best bet is to probably use something like a lua based db - https://github.com/nrk/redis-lua
This could be converted easily enough to work with a redis keystore - need to replace the luasocket calls with Defold socket calls 
