Compiling native JNI code for Android?

[lukeaschenbrenner]

Hello,
I am a relatively rookie developer working on an app for Android that requires the use of brotli encoding/compression. Google has already provided a brotli decoding library that works with Android ( https://mvnrepository.com/artifact/org.brotli/dec/0.1.2 ) but encoding isn't implemented in their library. What steps would one need to take to create native code (something to do with JNI?) that works on Android in order to use Brotli4j?
Thank you!

[hyperxpro]

If I'm correct then you can use Brotli4j linux_aarch64 for running on Android. No need for any extra compilations.

[lukeaschenbrenner]

Thank you for the reply, I will test and report back soon.

[lukeaschenbrenner]

@hyperxpro Just a quick update: I tried to run Brotli4jLoader.ensureAvailability() but the code threw this exception:
java.lang.UnsatisfiedLinkError: Failed to load Brotli native library at com.aayushatharva.brotli4j.Brotli4jLoader.ensureAvailability(Brotli4jLoader.java:79)
I'm guessing this means that it was unable to find the JNI bindings that worked with Android?
For reference, this is the relevant part of my current app module's build.gradle file:

    implementation("com.aayushatharva.brotli4j:brotli4j:1.8.0")
    runtimeOnly(
            "com.aayushatharva.brotli4j:native-linux-aarch64:1.8.0"
    )

Please let me know if I did anything wrong!
(Just to double check, it is my understanding that the enclosed import in runtimeOnly makes sure only the aarch64 linux bindings are compiled when building an APK, but when running a build in Android Studio, the implementation line copies all the bindings over from all platforms? This is my current understanding, but I'm worried that my understanding may be flawed.

Thank you very much for your help, I appreciate it.

[hyperxpro]

Can you show full stack trace so it'll be easier to debug?

[lukeaschenbrenner]

Sure thing! This was the full stack trace from the error:

2022-11-16 18:19:38.498 6455-6455/com.txtnet.txtnetbrowser D/AndroidRuntime: Shutting down VM
2022-11-16 18:19:38.500 6455-6455/com.txtnet.txtnetbrowser E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.txtnet.txtnetbrowser, PID: 6455
    java.lang.UnsatisfiedLinkError: Failed to load Brotli native library
        at com.aayushatharva.brotli4j.Brotli4jLoader.ensureAvailability(Brotli4jLoader.java:79)
        at com.txtnet.txtnetbrowser.MainBrowserScreen$7.onClick(MainBrowserScreen.java:287)
        at android.view.View.performClick(View.java:7455)
        at android.view.View.performClickInternal(View.java:7432)
        at android.view.View.access$3700(View.java:835)
        at android.view.View$PerformClick.run(View.java:28810)
        at android.os.Handler.handleCallback(Handler.java:938)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loopOnce(Looper.java:201)
        at android.os.Looper.loop(Looper.java:288)
        at android.app.ActivityThread.main(ActivityThread.java:7870)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
     Caused by: java.lang.NullPointerException
        at java.util.Objects.requireNonNull(Objects.java:220)
        at java.nio.file.Files.copy(Files.java:2984)
        at com.aayushatharva.brotli4j.Brotli4jLoader.<clinit>(Brotli4jLoader.java:50)
        at com.aayushatharva.brotli4j.Brotli4jLoader.ensureAvailability(Brotli4jLoader.java:78)
        at com.txtnet.txtnetbrowser.MainBrowserScreen$7.onClick(MainBrowserScreen.java:287) 
        at android.view.View.performClick(View.java:7455) 
        at android.view.View.performClickInternal(View.java:7432) 
        at android.view.View.access$3700(View.java:835) 
        at android.view.View$PerformClick.run(View.java:28810) 
        at android.os.Handler.handleCallback(Handler.java:938) 
        at android.os.Handler.dispatchMessage(Handler.java:99) 
        at android.os.Looper.loopOnce(Looper.java:201) 
        at android.os.Looper.loop(Looper.java:288) 
        at android.app.ActivityThread.main(ActivityThread.java:7870) 
        at java.lang.reflect.Method.invoke(Native Method) 
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548) 
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003) 
2022-11-16 18:19:38.512 6455-6455/com.txtnet.txtnetbrowser I/Process: Sending signal. PID: 6455 SIG: 9

Let me know if that's not enough, or if you need me to test something.

[lukeaschenbrenner]

Hello,
Just checking in to see if you have any updates on how this stack trace should be interpreted.

[hyperxpro]

Sorry I missed this. I'll get back to you with a solution.

[lukeaschenbrenner]

Thank you for responding! No problem. Let me know if I can help in any way; I would be interested in learning more about compiling the binaries you provide for different target architectures.
I discovered a port of Brotli to Haxe, which compiles to Java source code. I have yet to test it on Android but it looks to be platform independent. If an Android ARMv7 binary isn't possible with BrotliJ4, at least I will have an alternative.

[hyperxpro]

Sorry to say this I won't be supporting ARMv7 build for a while. But I will definitely consider this in the future.

[lukeaschenbrenner]

I understand, thank you for letting me know and I appreciate that you're looking into it for the future. Do you have any links or resources that might help to explain the process of compiling native code to work with Java using JNI bindings? I don't know if I'd be able to, but I'd like attempt to learn the basics myself and maybe take a shot at compiling for ARMv7 myself.

[hyperxpro]

You can take a look at this PR #66 to see how it is gonna work.

I am also trying because I don't have first-hand experience in compiling for ArmV7. :(

[hyperxpro]

I added the ARMv7 module. PTAL #67 :)

[lukeaschenbrenner]

Thank you so much! I attempted to build the object file for ARMv7 myself but the build failed. It seems as though the GitHub actions for the JDK17 docker action in the armv7 branch failed too (Docker seems to be running for that build on amd64, so it can't compile for arm32v7). I didn't see any generated artifacts for the JDK 8 build either. It's possible this is a simple fix, but I have never used GitHub actions before.