Android/pl
│
English (en) │
español (es) │
français (fr) │
polski (pl) │
русский (ru) │
Wszystkie artykuły dotyczące Androida są wymienione w Portal:Android.
Ten artykuł odnosi się tylko do systemu Android.
Zobacz także: Przewodnik programowania wieloplatformowego
Cel na Androida
Wsparcie dla docelowego systemu Android jest dostępne od FPC 3.0.
Obsługiwane procesory:
- ARM (
CPU_TARGET=arm
) - x86 (
CPU_TARGET=i386
) - MIPS (
CPU_TARGET=mipsel
) - ARM64 (
CPU_TARGET=aaarch64
) - w FPC 3.2+ - x86-64 (
CPU_TARGET=x86_64
) - w FPC 3.2+ - JVM (nie omówione na tej stronie)
Android NDK
Musisz pobrać i zainstalować Android NDK, aby uzyskać binarne narzędzia krzyżowe, które kompilują programy dla systemu Android na Twoim obecnym komputerze.
Pobierz Android NDK, korzystając z tego linku: https://developer.android.com/ndk/downloads/index.html
Wypakuj go do jakiegoś folderu.
Pobierz FPC dla Androida
Wersja wydania
Jeśli programujesz dla systemu Android na komputerze z systemem Windows, możesz pobrać pakiet instalacyjny, który zawiera kompilatory skrośne dla systemu Android (ARM, i386, MIPS). Po zainstalowaniu cross-kompilatorów możesz budować binaria dla Androida bez żadnych dodatkowych czynności.
W przypadku innych platform hosta musisz pobrać archiwum źródeł FPC i zbudować kompilator skrośny, jak opisano poniżej.
Pobierz najnowsze wersje cross-kompilatorów i źródła FPC tutaj: http://freepascal.org/download.html
Wersja rozwojowa/deweloperska
Wersja rozwojowa (trunk) FPC może zawierać nowe funkcje lub poprawki błędów w porównaniu z najnowszą wydaną wersją.
Sprawdź najnowsze źródła trunk FPC za pomocą następującego polecenia:
svn co http://svn.freepascal.org/svn/fpc/trunk fpcsrc
Teraz masz najnowsze źródła kompilatora w podfolderze fpcsrc.
Budowanie kompilatora skrośnego
Aby utworzyć kompilator skrośny, musisz mieć działającą instalację najnowszej wersji FPC dla swojej platformy hosta.
W tym samouczku opisano, jak zbudować kompilator skrośny docelowo dlaarm-android
w systemie Windows. Ale samouczek można zastosować do dowolnego systemu z niewielkimi oczywistymi modyfikacjami.
Use the similar approach to build a aarch64-android
or i386-android
or x86_64-android
or mipsel-android
cross-compiler.
Użyj podobnego podejścia, aby zbudować kompilator skrośny aarch64-android
, i386-android
, x86_64-android
lub mipsel-android
.
Załóżmy, że mamy następujące ścieżki:
- Ścieżka Android NDK:
C:\Program Files\Android SDK\android-ndk-r12b
- Ścieżka źródeł FPC svn:
C:\Develop\FPC\fpcsrc
- Ścieżka instalacji kompilatora skrośnego:
C:\Develop\FPC\pp
Dodaj ścieżkę do binutils systemu Android, do zmiennej środowiskowej PATH. W tym samouczku ta ścieżka to:
C:\Program Files\Android SDK\android-ndk-r12b\toolchains\arm-linux-androideabi-4.9\prebuilt\windows\bin
Otwórz wiersz poleceń i przejdź do katalogu głównego folderu źródeł FPC: cd C:\Develop\FPC\fpcsrc
Wykonaj następujące polecenie:
make clean crossall crossinstall OS_TARGET=android CPU_TARGET=arm INSTALL_PREFIX=C:\Develop\FPC\pp
Następnie powinieneś mieć zainstalowany kompilator skrośny i moduły w folderze C:\Develop\FPC\pp
.
Domyślnie wszystkie moduły są zbudowane z przełącznikiem optymalizacji -O2. Również programowa emulacja FPU jest używana domyślnie dla procesora ARM. Jeśli musisz określić różne opcje kompilatora do kompilacji, użyj parametru CROSSOPT
. Na przykład, jeśli chcesz zbudować moduł ze sprzętową obsługą FPU i procesorem ARMv7a, użyj następującego polecenia:
make clean crossall crossinstall OS_TARGET=android CPU_TARGET=arm CROSSOPT="-Cparmv7a -Cfvfpv3" INSTALL_PREFIX=C:\Develop\FPC\pp
Teraz utwórz nowy plik fpc.cfg
w folderze C:\Develop\FPC\pp\bin\i386-win32
i wklej do niego następujący tekst:
-FuC:\Develop\FPC\pp\units\$FPCTARGET\* #ifdef android #ifdef cpuarm -FlC:\Program Files\Android SDK\android-ndk-r12b\platforms\android-21\arch-arm\usr\lib #endif #ifdef cpuaarch64 -FlC:\Program Files\Android SDK\android-ndk-r12b\platforms\android-21\arch-arm64\usr\lib #endif #ifdef cpui386 -FlC:\Program Files\Android SDK\android-ndk-r12b\platforms\android-21\arch-x86\usr\lib #endif #ifdef cpux86_64 -FlC:\Program Files\Android SDK\android-ndk-r12b\platforms\android-21\arch-x86_64\usr\lib #endif #ifdef cpumips32 -FlC:\Program Files\Android SDK\android-ndk-r12b\platforms\android-21\arch-mips\usr\lib #endif #endif
Compiling programs
Now, when the cross-compiler is ready, you can compile programs for the Android target:
C:\Develop\FPC\pp\bin\i386-win32\ppcrossarm -Tandroid testprog.pas
Notes
- The compiler does NOT define
LINUX
during compilation! It definesUNIX
andANDROID
though.
(Background: Android is not completely Linux compatible, e.g. a few syscalls and default library functions e.g. in pthreads, ... are missing, and it generally behaves different in a few ways. This makes the amount of defines manageable by avoidingif defined(linux) and not defined(android)
. Actually, the list of things that are different is only growing).
- Shared libraries do not have
argc/argv
available (i.e. set to 0 or nil) because of Android.
- The System unit contains some useful Android-specific functions.
- The compiler and RTL do special processing for JNI shared libraries. The compiler treats a library as a JNI library only if the library exports the
JNI_OnLoad
function. Therefore, if you are creating a JNI shared library, always exportJNI_OnLoad
, even if it is empty.
- For JNI shared libraries standard output and error output are redirected to the Android system log. Therefore you can use
writeln()
to write to the system log.
- By default FPC builds PIC enabled shared libraries and executables for the Android target. PIC shared libraries work on any Android version (tested even on Android 1.5). But PIC executables can run only on Android 4.1+. To run executables on older versions of Android you need to disable PIC by passing the
-Cg-
switch to the compiler.
Known issues
- Shared libraries compiled with FPC 3.0 does not work on Android 6.0+ and executables does not run on Android 5.0+. Starting from Android 6.0 (Marshmallow), it is required to build PIC compatible shared libraries. Starting from Android 5.0 (Lollipop), it is required to build PIC compatible executables (PIE).
PIC support for the Android target is present starting from FPC 3.0.2.
NOTE: By default FPC 3.0.2+ builds PIC enabled shared libraries and executables for the Android target. PIC shared libraries work on any Android version (tested even on Android 1.5). But PIC executables can run only on Android 4.1+. To run executables on older versions of Android you need to disable PIC by passing the-Cg-
switch to the compiler. - Shared libraries compiled with FPC 3.0.x does not work on Android 8.0+ when an application targets API 26+. This is caused by usage of syscalls which are blocked by SECCOMP starting from Android 8.
This issue is fixed in FPC 3.2. - If you use the cwstring unit in a JNI shared library, your Java application will hang when loading the library on Android 4.0 or earlier. This also applies to any unit which dynamically loads shared libraries during initialization. See more information below.
This issue is fixed in FPC 3.2. - The clocale unit is not implemented in FPC 3.0.
It is implemented in FPC 3.2. - The netdb unit is unusable in FPC 3.0 due to missing configuration of DNS servers.
This issue is fixed in FPC 3.2. - The
Now
function always returns a GMT time in FPC 3.0.
This issue is fixed in FPC 3.2. - The following functions return unusable paths in FPC 3.0:
GetTempDir, GetAppConfigDir, GetAppConfigFile, GetUserDir
.
This issue is fixed in FPC 3.2.
If your shared library contains a unit which performs dynamic loading of other shared libraries using LoadLibaray()
or dlopen()
, your library may fail to load on Android 4.0 or earlier. The library loading will freeze in such case. One of the units, which can trigger the issue is cwstring.
Due to a bug in Android versions prior to 4.1, the dlopen()
API function does not support recursive calls. When a shared library is being loaded by JVM, using dlopen()
, the library initialization is executed, including initialization code of all units in the library. If a unit initialization code calls dlopen()
- it simply hangs, since the initial dlopen()
is not finished yet and recursion is not allowed.
This issue is fixed in FPC 3.2.0: To workaround this issue the compiler uses the following trick: If a library exports JNI_OnLoad()
, then no unit initialization is performed during library load. The initialization is called when JVM has loaded the library and then calls JNI_OnLoad()
.
Therefore, if you are creating a JNI shared library, always export JNI_OnLoad
, even if it is empty.
Also you can trigger this bug if you have a JNI shared library, which use other shared library, created using FPC. The loading of this second library may hang. To workaround this, you need to export an empty JNI_OnLoad()
function in the second library. Then you need to call JNI_OnLoad()
from the initialization of the first library.
See also
- Android tutorial
- You can use the pas2jni utility to easily create JNI shared libraries from your existing code and use it in Android native Java applications.
- Cross compiling for cross compiling from Linux, macOS and Windows along with other useful cross-compilation information.
External links
- Tutorial "Lazarus and Android" (PDF file)
- How to create Android apps with Lazarus
- How to setup cross-compilation to Android (Lazarus Forum)