Building a .so for use by an Android Java app lazarus / 43-Android ---------------------------------------------------------------------- MG · 2013-10-12 23:19 I'm looking at ways to port one of my Delphi apps to Android.  I looked at XE5, but it looks like there will be quite a lot of changes to make to the code due to their zero-based strings.  Plus FireMonkey has some limitations in its UI components that I'd prefer not to have to deal with.  For example, a twebbrowser can only display in full screen mode, making it next to useless for me.  I looked at oxygene as well, but that would require even more changes to the code.  One of my alternate options is to use FPC to compile a shared object that can be called by a Java-based Android app using JNI.  Luckily, in this case, the .so would have all of one function in it.  I can pass in a few parameters, and get a result back.  Completely self- contained, and the library wouldnt have to interact with the OS.  Since I had a version of my app built w/ Lazarus for WinCE, I know the library I'm using will compile well with FPC, so this seemed like a reasonable approach to look at. 1)Has anyone taken that approach and successfully published an app like that on Google Play?    Is that a realiable approach? 2) If this sounds like a reasonable approach, is there anything specific needed to do to compile a .so that can be used by an Android app? (special command line options required?) Thanks! ---------------------------------------------------------------------- Leledumbo · 2013-10-13 04:53 Quote1)Has anyone taken that approach and successfully published an app like that on Google Play?    Is that a realiable approach?No idea about google play publishing but that should be reliable Quote2) If this sounds like a reasonable approach, is there anything specific needed to do to compile a .so that can be used by an Android app? (special command line options required?)It's no different than existing LCL Custom Drawn .so used for Android target. Use fpc trunk with arm-android target support, ensuring the chosen floating point format (well, if you do floating point calculation) supported by your target device. Some Android devices are x86 based, so your app won't run there. ---------------------------------------------------------------------- engkin · 2013-10-13 20:10 A single apk file may include more than one ".so", for different CPU architectures, located in different folders under lib: lib    ----- armeabi/libexample.so       ----- armeabi-v7a/libexample.so    ----- x86/libexample.so In this case this apk may run on wider range of devices with ARM, ARMv7 and Intel CPUs. When you finish porting your application to any CPU you can generate the other two by changing settings and providing expected NDK toolchain binaries and rebuilding components and packages with the new settings. I believe you need to change Compiler Options in three different frames titled Paths, Code Generation, and Other. Example settings for using ndk r7c to compile liblclapp.so: Settings for ARM: Paths ---Libraries (-Fl) c:\android-ndk-r7c\platforms\android-14\arch- arm\usr\lib\ ---Target file name (-o) android\libs\armeabi\liblclapp.so Code Generation ---Target OS (-T) Android ---Target CPU family (-P) arm Other ---Custom options -dANDROID -Xd -CpARMV6 Settings for ARMv7: Paths ---Libraries (-Fl) c:\android-ndk-r7c\platforms\android-14\arch- arm\usr\lib\ ---Target file name (-o) android\libs\armeabi-v7a\liblclapp.so Code Generation ---Target OS (-T) Android ---Target CPU family (-P) arm Other ---Custom options -dANDROID -Xd -CpARMV7A Settings for x86: Paths ---Libraries (-Fl) c:\android- ndk-r7c\platforms\android-14\arch-x86\usr\lib\ ---Target file name (-o) android\libs\x86\liblclapp.so Code Generation ---Target OS (-T) Android ---Target CPU family (-P) i386 Other ---Custom options -dANDROID -Xd For ARM and ARMv7a you can choose between hardware (-CfVfpV2 or -CfVfpV3) or software emulated floating point operations (-CfSoft) by adding this setting to Custom options under Other If you decided to support more than one cpu and to include more than one .so in your apk I would suggest that you use Build Modes. In this case you write your settings once and you switch between different build modes to get a different .so. In case speed is not an issue, it seems that devices with Intel CPUs come with a library called Houdini that makes them capable of running most ARM code but with a lower speed. To start you might want to try Laz4Android. TrueTom, a member here, prepared it. You will need ndk r7c and JDK 1.6. ---------------------------------------------------------------------- MG · 2013-10-20 06:45 Thanks for the info engkin!  I'll give it a shot and see how it goes. ---------------------------------------------------------------------- TurboRascal · 2013-11-22 12:04 That's a very good approach, practically every serious app have great portions of code in libs (e.g. VLC, most games, chat/VoIP software etc). For several of those the size of libs exceeds the main apk size! So I guess in such cases all CPU intensive stuff is compiled natively into the lib, and the java code in main apk really just contains the GUI. ---------------------------------------------------------------------- yuriy_sydorov · 2013-12-23 17:24 If it is needed to reuse Pascal code from an Android Java app take a look at the pas2jni utility bundled with FPC trunk. Details here: http://forum.lazarus.freepascal.org/index.php/topic,21140.0.html