Hello,

There was already a previous thread about Android apps with JNI, so I thought I should start one for discussing non-JNI apps, which means that I am really running executables as opposed to linking a .so to Java via JNI.

I succeeded in running a simple FPC Pascal application in Android and showing it's WriteLn output in a message dialog:

http://p-tools.svn.sourceforge.net/viewvc/p-tools/PascalNotes4Android/?pathrev=190

Basically you need to rename your app so that it looks like a .so and then upon initialization the Java app needs to copy it to a folder where it can run the application. The folder is returned by getApplicationContext().getFilesDir which points to /data/data/packagename/ and then I use chmod to make the executable runnable.

I don't know how it will fare for apps running for prolonged amounts of time at the moment, some Android developers said it is possible that it won't work.

The Pascal app needs to be compiled separately and placed in the lib/eabi folder. Then after that issue "ant debug" to build the APK installer.

bye,

Hello,

It might be interesting to know that I managed to build a bridge which exports the Java API and the Android API to Free Pascal. Check this hello world code and screenshot:

http://wiki.lazarus.freepascal.org/Android_Interface/Android_Programming#Using_the_Android_API_from_Pascal

The full code is here:

http://p-tools.svn.sourceforge.net/viewvc/p-tools/PascalNotes4Android/

bye,

The Android 2.3 ndk now has support for a NativeActivity and there is a sample of OpenGL ES native program.

<quote>

General notes:

* Adds support for native activities, which allows you to implement the Android application lifecycle in native code.
* Adds native support for the following:
o Input subsystem (such as the keyboard and touch screen) o Access to sensor data (accelerometer, compass,
gyroscope, etc).
o Event loop APIs to wait for things such as input and sensor events.
o Window and surface subsystem
o Audio APIs based on the OpenSL ES standard that support playback and recording as well as control over platform audio effects o Access to assets packaged in an .apk file.

</quote>

I a

On Dec 17, 2010 8:47 PM, "Andrew Haines" wrote:

Felipe Monteiro de Carvalho wrote

Hello, It might be interesting to know ...

The Android 2.3 ndk now has support for a NativeActivity and there is a sample of OpenGL ES native program.

<quote>

General notes:

* Adds support for native activities, which allows you to implement the Android application lifecycle in native code.
* Adds native support for the following:
o Input subsystem (such as the keyboard and touch screen) o Access to sensor data (accelerometer, compass,
gyroscope, etc).
o Event loop APIs to wait for things such as input and sensor events.
o Window and surface subsystem
o Audio APIs based on the OpenSL ES standard that support playback and recording as well as control over platform audio effects o Access to assets packaged in an .apk file.

</quote>

Felipe Monteiro de Carvalho wrote

I a

??

Looks like someone may have hit the send button too soon :D

ahahah, I was writing an answer in my phone, but then gave up. Probably hit the send button by accident.

Anyway, yes, I had also seen that one and it is a step in the right direction =)

I haven't yet fully understood how this new APIs work, hopefully they are C APIs, if they are C++ APIs then it is just better to make Java calls like I can already do now. Another problem is that it doesn't solve the main issue which is that Android does not officially support running native programs, they need to be libraries. Of course I ignored this and managed to run native programs, but that's another story.

In short I don't think that I will change my development strategy for now, specially since I already bought a Android 2.1 phone and I can write Pascal apps for it at the moment and I don't plan on dropping support for it at the moment.

Of course that I might migrate to use this newer possibilities when I have exhausted that my current strategy can provide =)

On Sat, Dec 18, 2010 at 1:13 PM, Felipe Monteiro de Carvalho <

Felipe, great to hear, and probably since Android is OSS, your method modified or not will work for long, won't it? And also, does a general developer need some special skills/actions currently in order to run your program on a stock android phone?

Max Vlasov

They are C APIs indeed. I just took a stab at it, and after a long day of pointer errors in converted C code and really, really badly descriptions of error messages, I managed to port the example from here http://developer.android.com/reference/android/app/NativeActivity.html to FPC

Code here: http://j-software.dk/android.zip
Simply run lazbuild test.lpi in the jni dir, and then run ant debug/ant install in the root dir

The NativeActivity class allows you to load a shared library and run an exported method without any Java it's just a matter of converting all the required Android headers, and repurposing the existing Unix units(lots of libnames are different) and you can have a pretty non-hacky interface to lowlevel stuff from FPC.

Of course this doesn't solve any of the user interface problems, but I'm pretty sure it's a way better solution than copying applications and piping data to and from them

What FPC did you use? Just a plain arm compiler with an eabi rtl?

I thought 2.3 support now native apps using the android user interface?

Just a plain arm compiler(something close to trunk revision) and an eabi rtl, yes

> Of course this doesn't solve any of the user interface problems, but I'm I thought 2.3 support now native apps using the android user interface?

I don't think so. At least I can't find any mention of anything resembling that in the header files of the NDK. You can get access to native windows and draw to its surface, but you can't use native ui controls(TextView, etc)

Florian Klämpfl wrote

What FPC did you use? Just a plain arm compiler with an eabi rtl?

Software floating point should be activated too, because most phones have no FPU.

I thought 2.3 support now native apps using the android user interface?

It is getting closer, but still, not really.

Hello,

What about putting your units in the lazarus-ccr? I also want to use parts of it (at the moment I am interested in log.pas), so we should keep files in a central repository easily accessible for everyone and the Lazarus-ccr is the best place for emergent projects. Then we can colaborate on the development of common parts.

If you want I can put the units there and send you a link.

thanks,

I think you can put the units there if you want. I can't figure that site out

I forgot to put a mention in there that the log and jni unit come from Benjamin Rosseaux's example here:
http://vserver.rosseaux.net/stuff/FPCAndroidJNINativeTest.zip The other units are conversions from the latest NDK

Jeppe Johansen wrote

I think you can put the units there if you want. I can't figure that site out

It's a source forge project. I added the files here:

http://lazarus-ccr.svn.sourceforge.net/viewvc/lazarus-ccr/bindings/android-ndk/

If you would like to maintain them, please send me your source forge login and I'll give you commit rights to the repository.