[fpc-pascal] fpc code for Java class and Android.

[Jon Foster]

On 04/09/2017 11:30 AM, Paul Breneman wrote:
> On 04/09/2017 11:32 AM, fredvs wrote:
>>> For this, Xorg must be installed.
>>
>> Huh, of course only for gui applications (fpGUI or MSEgui).
>>
>> For no gui console application, compile your fpc java native library for 
>> the
>> same cpu than the one of Android.
>> For example RPi (but I am not sure it is the same cpu as android-devices).
>
> I'd like to try console apps (also with Free Vision) first in conjunction 
> with this:
>   http://turbocontrol.com/gnuroot.htm
The only thing that console apps need is a terminal emulator. A bunch of 
ways that can happen and it depends on whether this is to be provided 
through the Android market or not. If not things are much easier. Terminal 
emulators abound you can pretty much just pick one.

Now for the obstacles:

1.  Linux (Android kernel) only runs executables from a file system that 
allows you to set the "execute" permission, which means that you can't just 
put your stuff on an SD card and run it, since FAT and descendants don't 
have that permission. So you have to get your exes into the internal 
non-FAT App storage and Android permissions throw up plenty of barriers.

2.  Compiling for ARM. This can be done with cross build tools, with an ARM 
Linux computer or some other *nix variant available on ARM, or with several 
of the Android apps that provide pre-built versions of the compiler and a 
term environment. I actually built the compiler and tools with a CHIP / 
PocketCHIP (http://getchip.com/). Very inexpensive full blown Debian 8 
install. But I think I had to build a bootstrap compiler with my Intel 
based Linux box first. Which meant building a cross "binutils" for ARM, 
which was fairly simple. I can probably post some scripts if desired.

My final solution for compiling and running things was "Terminal IDE" Its 
setup for Java, C & C++ but it provides the terminal, assembler, linker, 
some Android packaging tools and it provides full access to the packages 
"home" folder which allows the executable permission. If there is an ARM 
bootstrap compiler, and I haven't looked in a while, you should be able to 
build FPC and units all from within Terminal IDE. You will want to use the 
automated installer for the C compiler and stuff, since that contains 
"binutils" (assembler, linker, ...).

*NOTE* Last I looked this won't work on Android 5+, explained below (#3).

My problem with it is "vi" for editing. And since other apps don't have 
access to its "sandbox" you have to do some juggling for a complete on 
device dev environment. It would technically be possible to keep source on 
the FAT storage (SD or internal) and just build into the sandbox, which has 
permissions.

You will need a ".fpc.cfg" in the IDE's home folder and you won't be able 
to install one to "/etc". You can find the correct location by typing "echo 
$HOME" (case is significant) in the terminal window.

I should also mention that the "hacker's keyboard" is very desirable for 
this. But you will probably want a larger screen size. Those buttons can 
get pretty small!

3.  Android 5+ introduced *mandatory* address space randomization. This 
means that binaries compiled for <5 won't run on 5+ and visa-versa. It also 
means you need address independent output from FPC for 5+. I believe this 
is now an option in FPC 3. But I don't believe the Terminal IDE guy ever 
produced a build that will work on Android 5+.

If distributing you will probably want to build both an address independent 
and non-independent version and then selectively launch the correct one. 
But that ties in with 4 & 5 below.

4.  Google does not allow one package to require another package. So your 
package has to be self contained, meaning that if you need an X server or 
Terminal emulator it has to be combined into one package with your fpc 
binaries and data. This has licensing implications that may not be 
acceptable. Depending on your situation you may be able to take someone 
else's OpenSource package and hack your stuff into it. ie. Get an open 
source term app, "rebrand" it, inject your FPC app, and patch it to 
auto-start your app and shutdown when your app finishes.

5.  Android *only* launches Dalvik (Java) based apps so if packaging you 
have to provide some kind of Java based wrapper anyways. Making #4 
mandatory anyways.

6.  App lifespan. Terminal apps expect that they will start and run until 
either their task has finished or the user signals it to stop. Android 
expects it can terminate and restart apps as it sees fit. This can cause 
problems when your app unexpectedly gets terminated.

I should also mention that the JVM target for FPC seems to work quite well. 
So its possible to use FPC to write the mandatory Dalvik wrapper for your 
native FPC code. I have an App that I kept the same core code and wrote a 
new Dalvik front end in FPC, using the JVM target. But its very time 
consuming and fraught with peril. The Android UI does many unexpected 
things and the Java environment has many obstacles that we FPC users don't 
expect. And FPC hasn't ported their units so you'll need the Android API 
reference handy and will have to dig for normal things like converting an 
integer to a string. And then there is the renaming of stuff done by the 
FPC API converter and ...

I'm sure I haven't listed all of the obstacles. But those are the majors. I 
also don't have a single solution that will work reliably. Depending on 
needs/wants you may be able to work out something that you can use. Right 
now I'm looking over fpGUI with an eye to porting it to Android to make a 
more sane environment.


-- 

Sent from my Debian Linux laptop -- http://www.debian.org/intro/about

Jon Foster
JF Possibilities, Inc.
jon at jfpossibilities.com