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.
j...@jfpossibilities.com
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
