Hello,

I've done a working Free Pascal android JNI example (with working .apk for current ARM-based Android device of the second device generation (because with VFPv3, so Motorola Droid/Milestone, HTC Desire, Nexus One, Samsung Galaxy S, and so on) inside)

http://vserver.rosseaux.net/stuff/FPCAndroidJNINativeTest.zip

It contains androidprt0.as as replacement for the empty arm/linux dllprt0.as of the FreePascal RTL from the SVN, because otherwise the Android Dalvik VM refuses to load the .so library because of missed/absent global/import/export symbols (_haltproc_eabi, __strptr, __operatingsystem_parameter_argv and so on).

It contains also a own JNI header port from the Android NDK, and own ARM Toolchain hook binaries to inject some command line parameters to the original "as" and "ld" binary calls. For "as": "--march=armv7-a -mfloat-abi=softfp -mfpu=vfp3" and for "ld": "--fix-cortex-a8"

And important FPC parameters are -CpARMv6 -CfVFPV3

I've done it, because i'm needing my own ECMAScript 5th edition engine called BESEN in a Android project of me.

Someone can make maybe a true patch from this for FreePascal for a offical android target support in FreePascal. And my OpenGL ES 2.0 headers (what I did originally for Nokia N900 for Maemo 5) are already in the FPC bugtracker, which should also under Android after a single-line-change of the OpenGL ES library path.

Benjamin 'BeRo' Rosseaux

I'am not sure how this should be done: the fpc target is arm-linux so android is some kind of sub architecture. However, FPC has no infrastruture to support such sub targets/architectures. Maybe we should add some -W switch which allows to load settings for a certain sub architecture together with MACHINE_TARGET or something like this in the makefiles.

This sounds very interesting. I only played a little with FPC and Android, meaning I build the crosscompiler (which was quite easy) and tested some simple command line stuff. Of course I could not build .apks so my programs had to be uploaded and started via adb, but at least they worked fine. Unfortunately I currently have no time to play around with your code, but I will as soon as I can. From your mail it is not clear which ld and as you used. I just took them from the Android NDK, you too? Did you try if gdb and gprof are working?

All in all great work and perhaps you can claim the bounty: http://wiki.lazarus.freepascal.org/Bounties#Cross-Compile_to_Android_on_Ubuntu_X64

My compiler runs on Ubuntu64, so yours should too and with JNI you are able to build real .apks which I think is good enough to claim the bounty.

Thanks for showing us
R.

Reimar Grabowski wrote

From your mail it is not clear which ld and as you used. I just took them from the Android NDK, you too? Unfortunately I currently have no time to play around with your code, but I will as soon as I can.

Under linux I'm using self-built arm binutils, and under windows I'm using the YAGARTO "Yet another GNU ARM toolchain", because the original android NDK ARM binutils binaries are very buggy, at least the ld linker from it.

Did you try if gdb and gprof are working?

So far when I had time for this :-)

A lazarus android UI widget set is so far very difficult to make for now, because android's UI concept is very different from another UI concepts and therefore very difficult to adapt this concept for the LCL "in the current state". But a alternative way would be the way over a own OpenGL ES based GUI engine for android lazarus apps, but that would break the android UI design concept philosophy.

Short: My android JNI freepascal stuff is rather only for to speedup some things, for example DSP audio stuff, game rendering/complexlogic code, etc. all what will be as Java code a lot of slower than freepascal native code, but not for android UI things, sorry.

But Lazarus extending with a plain android JNI features (with automatic injecting into a "host Java JNI caller stub" apk and apk resigning) will be perharps posssible (for example for freepascal-based Android OpenGL ES games and so on, where no native android UI stuff is needed).

Benjamin 'BeRo' Rosseaux

Hello,

Did you try making executables for Android? It is possible to run native executables from Java.

That would be somewhat better then running the code from a .so

Also a tutorial about how to create the cross-compiler and set everything up would be excelent ...

From your zip file it seams that you based your work on Windows, correct?

thanks,

Did you try making executables for Android? It is possible to run native executables from Java.

It is not my code but I know a bit about Android.
I don't know of any way running native executables from Java on this platform. It is definitly not officially supported. You can run native FPC progs on Android devices via the development tools circumventing the official way to install software. You can start this progs from your pc but not from the device itself. Since you cannot distribute this kind of software via official channels (market and the like) it is not of much use. Also I don't really know how to interact with these kinds of programs or how to run a GUI.

That would be somewhat better then running the code from a .so

True, but as it is not supported there is no better way than to run your code from a lib. At least it is native then and you get the performance improvements. To my knowledge it is currently the best way to use FPC on Android. You must remember that Android apps are not really complete programs (as you know them) but some special Java classes that are run from an 'app manager'. You don't have the kind of control you know from conventional programs.

hih
R.

Reimar Grabowski wrote

I don't know of any way running native executables from Java on this platform. It is definitly not officially supported.

Here is a tutorial:

http://gimite.net/en/index.php?Run%20native%20executable%20in%20Android%20App

It just uses standard Android Java API calls AFAIK

Since you cannot distribute this kind of software via official channels (market and the like) it is not of much use.

Google does not impose this kind of limit on market applications. As long as you have the standard installer packages and has a stub Java program calling our Pascal app it should be fine.

Also I don't really know how to interact with these kinds of programs

The most workable that I found is through pipes between the Java and the FPC app.

Sockets are also a possibility, but I think (not sure) they will probably add more overhead then pipes.

or how to run a GUI.

This is the tricky part. The obvious answer is OpenGL ES.

I would like to use the Surface Manager C API instead, but I haven't found any documentation about it so OpenGL ES seams to be the workable solution.

Felipe Monteiro de Carvalho wrote

Did you try making executables for Android? It is possible to run native executables from Java.

I'm very interested in this too. My next toy is going to be a Android based tablet (mostly for ebook reading), but I would like to develop for it too.

Any info would be much appreciated.

Thanks for the tutorial, but as you surely have read (see comments) there are problems using this approach. And I won't hardly call it officially supported as it is a little hackish.

That is true but I was talking about running native FPC apps directly without calling them from Java.

> Also I don't really know how to interact with these kinds of programs The most workable that I found is through pipes between the Java and the FPC app.

And this is fast enough for realtime interaction?
If this is the case then it is a really nice solution. I am mostly interested in touch input and the sensors.

> or how to run a GUI. This is the tricky part. The obvious answer is OpenGL ES.

When it comes to graphics OpenGL is always the answer. ;)

Do you have any working example code?

R.

Because maybe requested of few, here is the complete source code of the android version of my BeRoXM mod/xm/wow player (which is also in the android market), where the mod/xm/wow playerengine is implemented in object pascal and compiled with freepascal, and the UI part stuff is in Java.

The url is: http://rootserver.rosseaux.net/stuff/BeRoXMAndroidSrc.zip

I hope it's a good start example now for these, who do want to mix object pascal code over the JNI bridge in their android app projects.

And I'm working on OpenGL ES 2.0 android game in he moment, which contains 99% object pascal code and only 1% java code for "native objpas code JNI library loading"+"Android input event hooking and redirect to native code"+"OpenGL ES 2.0 context
creation"+"Realtime-calculated-Audiobuffer-from-native-objpas-code-to-Android-Java-Audio-API-redirecting", but no more, so the remain of the code of my current android game project is pure object pascal, gne logic, opengl es 2.0 renderer, resource loading, threading (it has four threads, logic thread, render thread, audio thread and android UI event thread), networking, and so on.

Regards,
Benjamin 'BeRo' Rosseaux

On Thu, Nov 25, 2010 at 6:35 AM, Benjamin Jan Alexander Rosseaux <

Benjamin,
great to here, as long as I see there's no dedicated page about your experience with writing in Pascal for Android (only found your post in another forum:
http://www.pascalgamedevelopment.com/showthread.php?5818-BeRoXM-The-first-android-app-with-object-pascal-code), I hope the admins will allow and you probably will have time to write some info at fpc wiki.

Also I think that you as the developer who really did this, might add something useful to this sub-discussion:

Can you consider Android as the best mobile platform currently for a pascal developer?

Max Vlasov

Hello,

How do you compile BeRoXM? Using ant?

Also, installing BeRoXM.apk failed in HTC Wildfire Android 2.1

Also, I couldn't find the source code for the Pascal part.

thanks,

Felipe Monteiro de Carvalho wrote

Also, installing BeRoXM.apk failed in HTC Wildfire Android 2.1

I didn't check the log since I don't plan on using JNI anyway, but probably it was built for release but lacks the certificate. This issue confused me a bit.

ant debug

Should be used for building most of the time so that it adds the debug certificate.

Reimar Grabowski wrote

Thanks for the tutorial, but as you surely have read (see comments) there are problems using this approach. And I won't hardly call it officially supported as it is a little hackish.

I don't care about being officially supported or being hackish, I am only interrested if it works.

I just tryed and the tutorial doesn't work anymore, it works for Android up to 1.5 only

But I found an alternative very easy solution which works:

http://p-tools.svn.sourceforge.net/viewvc/p-tools/PascalNotes4Android/src/com/pascalnotes/PascalNotes4Android.java?revision=187&view=markup

I succeded at running ls /sdcard and showing the results in a message dialog =)

Next step is running a deployed Pascal application =D

You do need for BeRoXM a current midclass/highend android device with a ARM CPU, which supports the ARM v7a instruction set or better said the VFPv3 floatingpoint instruction set. The SoC in the Wildfire, which is a lowend android device, is still ARMv6, like the HTC Dream and Magic. Because BeRoXM depends on floating point calculations for the DSP audio lowpass/highpass coef calculations. My current FreePascal android projects are targeting only more for midrange&highend android devices (because i'm more the realtime multimedia audio/realtime 3D opengl es graphics guy), not for lowend still-ARMv6 devices, which will hopely die out by new lowend (today midrangeclass. then ex-midrangeclass lowend) devices with VFPv3 support in this next year.

The pascal part is under the jni/ folder in the ZIP.

In Android 2.3 you can write apps without any Java code, but you still need to build it as a library:

http://developer.android.com/reference/android/app/NativeActivity.html

It seams to support OpenGL and user input without Java.

Still not ideal, however.

Felipe Monteiro de Carvalho wrote

Still not ideal, however.

Well, no. As Android targets any processor - not just ARM. Indeed, there are Intel based versions. Native is bad, and only come in to existence to compete with other platforms with purely native compilation - and then purely to counteract criticisms on the performance of games and multimedia apps. Davlik was created for a reason - compile once, run on multiple targets. Would it not be a better solution to create a Dalvik back-end? As I understand it, Dalvik is very, far from a traditional stack based Java VM and closer to a traditional register based processor in design. I know little about it, but the benefits of Android, as a platform, are completely lost when one focuses on native compilation.

M

Matt Emson wrote

Well, no. As Android targets any processor - not just ARM. Indeed, there are Intel based versions.

I've never seen one and I've already worked with maybe 50 different Android smartphones / tablets.

x86-Android is negletible. I bet that it has less then 0.1% of the Android devices market share.

Native is bad

your opinion. I disagree.

Would it not be a better solution to create a Dalvik back-end?

1> This would be a huge, very hard task. Who will do it? I don't have the resources (time / money) to do it. If you have, I'm all for it that you do it! Good luck!

2> There are no guarantees that Dalvik's bytecode will remain compatible in the future. Google is being sued over Dalvik and might even decide to drop it completely as far as we know. If that happens, you just lost all your work.

3> Existing FPC applications would need to be modified to work in this FPC port. Think about pointers for example.

I don't see it that problematic to create a Dalvik code generator (or a normal Java or CIL one). The biggest problem is to create a suitable RTL and to be able to use the classes that are provided by the VM.

Regards,
Sven

In fact I think this is one of the more easy things. The main problem seems to me that you need to support things like pointers, which is something deeply embedded in Pascal.

Michael.

In our previous episode, Michael Van Canneyt said:

I think the "suitable RTL" is a reference to an earlier discussion about this subject, where this (pointers) was also said, and that maintaining an native RTL without pointers was not desirable. (and just after that is in the air the guaranteed destructors will start to that, and the systems will divergate more and more )

IOW, only the compiler frontend is shared, nothing else.

I think 'RTl' is way too limited in scope. Pointers are used in many many pascal sources.

Michael.

In our previous episode, Michael Van Canneyt said:

It goes of course even more for libraries above that level. I don't see any future for code sharing (rtl,libs) between bytecode and native. I've seen the mess with Delphi.NET on the delphi side, and don't want a slippery slope in that direction.

The pointers are just the first thing. Object model, RTTI etc are next.

But if the overlap with the bytecode generator is only in the compiler, then
that satisfies me, and is it something for the compiler devels to decide.

Native is bad, and only come in to existence to compete with other platforms with purely native compilation -

I disagree. Just the opposite. There were already lots of attempts to create a processor independend programming layer (i.e. USCD-Pascal with the p-code in the seventies) but none of them survived very long. They all had a great disadvantage: Bad performance. And it is quite evident, that if you would have a "universal API layer" then all processors would be the same. There would be no need to create new processors because they all would compute the same commands from the one and only API layer. I doubt that this idea will survive long.

Dear all,
I understand Delphi 2010 has changed its RTTI mechanism, and it is said to be much more usable than the previous one.
(see here for example: http://www.malcolmgroves.com/blog/?p=476)

What are the FPC team's plans about improving the RTTI? Any similar or as easy to use/powerful?
For example, are there any attributes?

Best regards,
Thierry

Thierry Coq wrote

What are the FPC team's plans about improving the RTTI? Any similar or as easy to use/powerful?

Anyone needing this is welcome to submit patches. I don't think anyone is working on it right now, or planning to in the near future.

For example, are there any attributes?

Not at this time.

Jonas

PS: please do not reply to existing messages when starting a new topic, it messes up threading both in the online archive and in many mail clients.

Hello, I am ressuscitating this ancient thread because I'd like to continue the talk about it =)

My main doubt here is if androidprt0.as is really required, which would mean that I can only produce android libraries if I make changes to the compiler.

Benjamin, couldn't one just declare the missing simbols in code? This would simplify things a bit.

Original message since most probably won't have it:

Hi,

Note that there is no dedicated android/arm support (or any arm support) for freepascal yet. In some circumstances the arm/linux stuff works.

Benjamin, couldn't one just declare the missing simbols in code? This would simplify things a bit.

An improved dllprt0.as has been created since, which works fine at least for arm/linux.

However, you might want to use the hack from
http://mantis.freepascal.org/view.php?id=18833 on android for now. If you can give me some documentation how/if argc/argv/envp are passed to a shared library on android, one could see if support can be added. I assume that some sort of new target may need to be added though.

You might want to check whether proper initialization and finalization is performed for those libraries correctly for arm/android. At least when using dlopen and friends on arm/linux (and others) this works.

When linking a FPC library using $LINKLIB, initialization/finalization is not called on several linux platforms (ppc/ppc64/arm) or crashes badly on unload at least on some linuxes (x86/amd64 on ubuntu).

Not sure whether the as/ld issues have been fixed in the meantime.

Hth,
Thomas

Hi,

meant "or any android support" here.

Hth,
Thomas

Thomas Schatzl wrote

However, you might want to use the hack from http://mantis.freepascal.org/view.php?id=18833 on android for now.

What do you think about merging this hack to trunk and to 2.6.0? I can do the commit on trunk.

I think that a hack support is better then no support at all.

If you can give me some documentation how/if argc/argv/envp are passed to a shared library on android

I have no idea.

When linking a FPC library using $LINKLIB, initialization/finalization is not called on several linux platforms (ppc/ppc64/arm) or crashes badly on unload at least on some linuxes (x86/amd64 on ubuntu).

=( The LCL contains initialization/finalization sections, so that could prevent the LCL to work via JNI.

Jonas

My main doubt here is if androidprt0.as is really required, which would mean that I can only produce android libraries if I make changes to the compiler.

In NativeTest\jni is a makeandroid.bat that assembles androidprt0 and calls ppcrossarm with -k"-landroidprt0". No need to change the compiler for that, unless there are conflicts with existing arm initialisation.

Ludo

Jonas Maebe wrote

No, hacks like that do not belong in trunk.

And about release branches then? Are hacks allowed to be merged directly to release branches?

Is that a joke? No, of course they aren't.

Jonas

Well, the hack doesn't seam to really work well anyway, because it crashes executables generated by the compiler =(

So one can either activate the hack and have a compiler only for DLLs or not have it and have a compiler only for executables...

Where does argv and argc come from? From dllprt0.as ?

Or more generally: Any ideas of where / what I should look for to fix this?

Hi Ludo.

I try to use you androidprt0.so but I keep getting the same error.

I do not have much experience in the lower parts of how the linking/assembling is done,
so I hope you can help me out here.

I get the following error:

$ ppcrossarm -b -B -XX -Xc -XD -Tlinux -darm -k"-landroidprt0" pascaljni.lpr Free Pascal Compiler version 2.4.4 [2011/11/18] for arm Copyright (c) 1993-2010 by Florian Klaempfl
Target OS: Linux for ARMEL
Compiling pascaljni.lpr
Assembling pascaljni
Linking libpascaljni.so
/usr/local/bin/arm-linux-ld: warning: link.res contains output sections; did you forget -T?
/usr/lib/fpc/2.4.4/units/arm-linux/rtl/dllprt0.o: In function `_haltproc': androidprt0.as:(.text+0x0): multiple definition of `_haltproc' ./libandroidprt0.so:androidprt0.as:(.text+0x0): first defined here /usr/lib/fpc/2.4.4/units/arm-linux/rtl/dllprt0.o: In function `_haltproc_eabi':
androidprt0.as:(.text+0x8): multiple definition of `_haltproc_eabi' ./libandroidprt0.so:androidprt0.as:(.text+0x8): first defined here /usr/lib/fpc/2.4.4/units/arm-linux/rtl/dllprt0.o:(.data+0x0): multiple definition of `operatingsystem_parameter_envp'
./libandroidprt0.so:(.data+0x0): first defined here /usr/lib/fpc/2.4.4/units/arm-linux/rtl/dllprt0.o:(.data+0x4): multiple definition of `operatingsystem_parameter_argc'
./libandroidprt0.so:(.data+0x4): first defined here /usr/lib/fpc/2.4.4/units/arm-linux/rtl/dllprt0.o:(.data+0x8): multiple definition of `operatingsystem_parameter_argv'
./libandroidprt0.so:(.data+0x8): first defined here pascaljni.lpr(19) Error: Error while linking
pascaljni.lpr(19) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted

As you can se i'm using FPC 2.4.4 (releases2_4_4 of the subversion repository) and there is clearly a conflict between two competing unit. But how do I resolve this?

Regards,
Torsten Bonde Christiansen.

A long time ago, august ;) , libandroidprt0 was a replacement for linux arm dllprt0.as that apparently was virtually empty. In the mean time dllprt0 contains all of libandroidprt0 + more. Hence the duplicate definitions. Just remove the -k"-landroidprt0". You won't miss anything.

A lot has changed since august and I haven't followed the development closely. I think you better refer to the work Felipe is doing on android. http://wiki.lazarus.freepascal.org/Android_Interface

Ludo

Is it still a problem to use libraries under android? I believe I read somewhere that the env pointer is not set correctly.

-Torsten.

FPC 2.6 and 2.7 are broken for Android. You can manually patch fpc to work around the issues.

See: http://bugs.freepascal.org/view.php?id=20726
and: http://bugs.freepascal.org/view.php?id=18833

If you don't want to wait until the bugs are fixed, AFAIK the best is using the compiler which is known to work very well, my precompiled snapshot for x86-linux -> arm-linux from 19th January:

http://sourceforge.net/projects/p-tools/files/Free%20Pascal%20for%20ARM/

If you want to build your own compiler then either try the source code from 19th January or patch your compiler to fix the Android problems.

I don't have any patches at hand here because I always use my snapshot, which always works for me.

Hello sir,

Read your posts. I 'm currently working on Lazarus android app programmin ,i request you to guide me on that .Plz mail me your contact id so that i can get in touch with you...you can add me on

Thank you

Regards

Hello,

For asking Android questions I recommend the Lazarus forum:

http://www.lazarus.freepascal.org/index.php/board,43.0.html