[SOLVED] LAMW: Add custom shared library to project

[jmpessoa]

Ok.

The github repository was updated!

Added support to custom library when "CanUpdateTemplate=True"

Thank you!

[yuriy_sydorov]

As I suspected Synapse does not work under Android.

Synapse works great on Android when using FPC trunk version.
There was a problem with DNS resolution (netdb) and it is fixed in the trunk.
See here the list of fixed issues: http://wiki.freepascal.org/Android#Known_issues

[tk]

Synapse works great on Android when using FPC trunk version.
There was a problem with DNS resolution (netdb) and it is fixed in the trunk.

I already made my own lightweight UDP client unit (no DNS and IP4 only, sufficient to what I need), see attachment, works very well for me (Linux+Android).
But I'll look at the FPC trunk version later, good to know that it already works.

[tk]

I did some test here... works as expected ...The jTime [and others] stuff was include and my "loadlibrary" was preserved in "Controls.java"...

Works for me now, don't know already what I made wrong before.

Added support to custom library when "CanUpdateTemplate=True"

Great! I'll check it out and report then!

[tk]

So I tried current git version but suddenly Controls.java was not updated at all.

I found relevant code in smartdesigner.pas but then inspected my java template path and it still pointed to the old location which I deleted. So it did not replace Controls.java.

Where can I set new java template location?
I don't see such entry in Tools/LAMW path settings.

Thank you

EDIT: Success! Had to add Java template path edit field to uformsettingspaths.pas and I was then able to change that path!
So works now, marking this solved.

Shall I send you my changes? The edit I added to that form is not properly aligned as I was not able to move fields on that form, don't know why... But the setting works.

PS. I was not able to find the location where the LAMW settings are stored on disk...

EDIT2: I attached the patch.

[tk]

And one more note to this (using the FPC trunk now):

GetAppConfigDir(False) returns correct config path only when called in the main app.
For the library it returns /data/local/tmp/ which is not anymore writable on recent Android versions.

It seems to me that GetHomeDir (which is called by GetAppConfigDir) is badly defined in SysUtils.pas as it relies on the IsJniLibrary variable. This variable is false in my library and IMO the configuration path should not be dependent on that variable.

I could normally obtain the path by using the same code and removing the IsJniLibrary check.

[jmpessoa]

Where can I set new java template location?
I don't see such entry in Tools/LAMW path settings.

go to foder "C:\lazarus\config" and edit "JNIAndroidProject.ini"

But, Ok I will apply your patch!

Thank you!

[yuriy_sydorov]

And one more note to this (using the FPC trunk now):

GetAppConfigDir(False) returns correct config path only when called in the main app.
For the library it returns /data/local/tmp/ which is not anymore writable on recent Android versions.

Just set IsJniLibrary to True in your external library to force GetAppConfigDir return correct path.

[yuriy_sydorov]

And one more note to this (using the FPC trunk now):

GetAppConfigDir(False) returns correct config path only when called in the main app.
For the library it returns /data/local/tmp/ which is not anymore writable on recent Android versions.

Just set IsJniLibrary to True in your external library to force GetAppConfigDir return correct path.

This issue has been fixed in r34926 in trunk. GetAppConfigDir() works for any shared library, if a package name can be detected.

[tk]

Thanks yury, good to know!

Until now I used the copy of GetAppConfigDir code for Android, did not want to alter IsJniLibrary variable in my library.
I'll pull the trunk via fpcupdeluxe again and try it!

[tk]

One more important note for shared libraries on Android.
If the library is NOT a JNI library (which I suppose is always the one created by LAMW) you have to simulate that, otherwise it will hang on Android systems <4.2!
At least this blocker comes with recent FPC trunk (downloaded a week ago).
The cause is well described in fpc source (compiler/systems/t_android.pas).
I spent hours and hours isolating the cause.

If coming to this issue and your library hangs on such old device, add this to your library:

Code: Pascal  [Select][+][-]

1. {$IFDEF ANDROID}
2. function JNI_OnLoad(VM: Pointer; {%H-}reserved: pointer): Longint; cdecl;
3. const
4.   JNI_VERSION_1_6=$00010006;
5. begin
6.   Result := JNI_VERSION_1_6;
7. end;
8.  
9. exports
10.   JNI_OnLoad name 'JNI_OnLoad';
11. {$ENDIF}

Note: In FPC that came with Laz4Android 1.5 the libraries work fine even without this fix. Clearly because there were huge changes made in Android RTL during this time.

Yury, as it seems you are the author of the new android RTL, did you make here something recently or what else would you recommend here?
Although this fix works (and even the GetAppConfigDir works because the RTL sets IsJNILibrary to true), it is quite a dirty fix.

[yuriy_sydorov]

Indeed, if you use the cwstring unit in a JNI shared library, your Java application will hang when loading the library on Android 4.0 or earlier. This also applies to any unit which dynamically loads shared libraries during initialization.
It is caused by a bug in older Android versions.

The issue is fixed only in FPC trunk. And your JNI library must export the JNI_OnLoad function in order the compiler be apple to apply needed workaround.

[tk]

Note: In FPC that came with Laz4Android 1.5 the libraries work fine even without this fix.

So it was clearly only a lucky coincidence that the older RTL (distributed with Laz4Android 1.5) did not call dlopen() during unit initializations (which actually causes the freeze).
Haven't tried but if it was called then there was a freeze as well.

[yuriy_sydorov]

So it was clearly only a lucky coincidence that the older RTL (distributed with Laz4Android 1.5) did not call dlopen() during unit initializations (which actually causes the freeze).
Haven't tried but if it was called then there was a freeze as well.

Probably the cwstring unit was not used in your library or dependent units when you compiled using Laz4Android 1.5. That's why there was no freeze on older Android versions. cwstring for Android preforms dynamic loading of ICU libraries from the beginning.

I've discovered this bug quite recently, despite I had been working on Android target for FPC for several years. I always performed FPC test suite runs on Android versions 4.1+ and all worked fine.

But when my own Android application has matured enough to require cwstring, I've found that it does not start on Android 2.3 anymore. And after some investigation the bug was discovered and fixed.