Add support for Android
Opened this issue · 8 comments
Currently, the Termux app provides openjdk-17 as a package which can run on Android devices. So gradle, maven etc packages are also needed to be add as a package for supporting building with Java. We already added the gradle package. But for maven, which uses your Jansi, doesn't support on terminal because of incompatible architecture, as Android doesn't have a library 'libc.so.6', showing error:
Please add support for Android platform, you can use the Android-NDK for compiling native libraries for various Android architectures, compiling with it will link 'libc.so' instead of 'libc.so.6' which is available in the Android OS framework.
~/nifi-1.15.0/minifi $ mvn --version
Failed to load native library:jansi-2.4.0-5abe82c1e27b751f-libjansi.so. osinfo: Linux/arm64
java.lang.UnsatisfiedLinkError: /data/data/com.termux/files/usr/tmp/jansi-2.4.0-5abe82c1e27b751f-libjansi.so: dlopen failed: library "libc.so.6" not found: needed by /data/data/com.termux/files/usr/tmp/jansi-2.4.0-5abe82c1e27b751f-libjansi.so in namespace (default) Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Maven home: /data/data/com.termux/files/usr/opt/maven
Java version: 17-internal, vendor: N/A, runtime: /data/data/com.termux/files/usr/opt/openjdk
Default locale: en, platform encoding: UTF-8 OS name: "linux", version: "4.19.127-g127475f6d88e-dirty", arch: "aarch64", family: "unix" ~/nifi-1.15.0/minifi $ java --version
openjdk 17-internal 2021-09-14 OpenJDK Runtime Environment (build 17-internal+0-adhoc..src) OpenJDK 64-Bit Server VM (build 17-internal+0-adhoc..src, mixed mode) ~/nifi-1.15.0/minifi $ javac --version
javac 17-internal
~/nifi-1.15.0/minifi $ mvn --version
Failed to load native library:jansi-2.4.0-5abe82c1e27b751f-libjansi.so. osinfo: Linux/arm64
java.lang.UnsatisfiedLinkError: /data/data/com.termux/files/usr/tmp/jansi-2.4.0-5abe82c1e27b751f-libjansi.so: dlopen failed: library "libc.so.6" not found: needed by /data/data/com.termux/files/usr/tmp/jansi-2.4.0-5abe82c1e27b751f-libjansi.so in namespace (default) Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Maven home: /data/data/com.termux/files/usr/opt/maven
Java version: 17-internal, vendor: N/A, runtime: /data/data/com.termux/files/usr/opt/openjdk
Default locale: en, platform encoding: UTF-8 OS name: "linux", version: "4.19.127-g127475f6d88e-dirty", arch: "aarch64", family: "unix" ~/nifi-1.15.0/minifi $ java --version
openjdk 17-internal 2021-09-14 OpenJDK Runtime Environment (build 17-internal+0-adhoc..src) OpenJDK 64-Bit Server VM (build 17-internal+0-adhoc..src, mixed mode) ~/nifi-1.15.0/minifi $ javac --version
javac 17-internal
I think it is possible to implement a provider based on the tty/stty command and use it for Android support.
After merging #270, I will to do some further refactoring.
I want jansi to use stty if jni is not available. In order to do this, I need to change the usage of jansi.graceful to decouple it from the jni provider.
After merging #270, I will to do some further refactoring.
I want jansi to use
sttyif jni is not available. In order to do this, I need to change the usage ofjansi.gracefulto decouple it from thejniprovider.
While I'm very glad you work on all those new features, but I'm really starting to wonder if it would make more sense to somehow merge jansi inside jline at some point, keeping jansi the low level library for jline capabilities. It really looks like a lot of duplication to me with all those providers, are a lot of this code is already present in jline and we're just missing the FFM (PR ready) and the new static-native one.
While I'm very glad you work on all those new features, but I'm really starting to wonder if it would make more sense to somehow merge jansi inside jline at some point, keeping jansi the low level library for jline capabilities. It really looks like a lot of duplication to me with all those providers, are a lot of this code is already present in jline and we're just missing the FFM (PR ready) and the new static-native one.
If there is no MingwSupport, then this point is debatable. But since we already have MingwSupport, what we need is already included in jansi, and #270 needs it to use it on Linux, so we don't need to add anything new after it, just make some adjustments to what we already have.
Other than that, the adjustments to jansi.graceful I think are leftover work after creating AnsiConsoleSupport. The current logic is a bit strange for AnsiConsoleSupport. If the user does not use the jni provider, this property will not take effect. At the same time, it will also cause the traversal of the provider list to stop on jni when -Djansi.graceful=true, even if jni is not working. So I think refactoring is necessary.
We really don't have much left to do beyond this necessary refactoring. I only had to edit AnsiConsoleSupportHolder slightly and get jansi working on any POSIX platform in less than ten lines of code.