Remove build instruction telling to use older NDK toolchain v25...

[bitmold]

@uniqx @n8fr8

I remember last spring I was updating a lot of tor-android deps, specifically going from the very old openssl1 to openssl3 series. At the time, I couldn't get this project to build with any NDK toolchains newer than the 25 series.

On a new machine running Debian Bookworm I just had success using the latest NDK toolchain offered by the SDK Manager in Android Studio version 29.0.13113456. It's hard to diagnose what fixed things here.... In the past 10 months or so, numerous dependencies of tor-android have been updated, various other project config stuff has changed, etc.

But anyway, if this toolchain works for everyone, we should be using it, and not a deprecated version.

[syphyr]

The problem with NDK tool chains newer than 25 is that they all strip the additional jni functions used by Orbot which are added to the Tor library, not that it builds "successfully". Have you checked that the added jni functions are still there in the new Tor library? I guess the best way to check this is to build Orbot with the new Tor library and see if there are any runtime exceptions on startup.

[syphyr]

I have just tested NDK 28.0.13004108 and NDK 29.0.13113456. Both of these versions still strip out the JNI symbols from libtor.so. Here is a way of testing this:

grep Java_org_torproject_jni_TorService_createTorConfiguration external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_mainConfigurationSetCommandLine external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_mainConfigurationSetupControlSocket external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_mainConfigurationFree external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_apiGetProviderVersion external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_runMain external/lib/arm64-v8a/libtor.so

For all of these commands above, the response should be "Binary file external/lib/arm64-v8a/libtor.so matches". If it does not say that, then Orbot will not work. There must be some kind of linking option that we are missing with the latest NDK. This all started with NDK 26.

[syphyr]

I think the way to fix this is with RegisterNatives instead of letting runtime look them up dynamically

[bitmold]

I was naive when casually returning to this problem a few months ago and misremembered in the past having compilation issues. Of course, what you said here is accurate @syphyr though I urgently want to move to a newer NDK and figure this out once and for all.

➜  a tor-android git:(master U:3 ✗) echo $ANDROID_NDK_HOME 
/home/a/Android/Sdk/ndk/25.2.9519653/
➜  a tor-android git:(master U:3 ✗) grep Java_org_torproject_jni_TorService_createTorConfiguration external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_mainConfigurationSetCommandLine external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_mainConfigurationSetupControlSocket external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_mainConfigurationFree external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_apiGetProviderVersion external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_runMain external/lib/arm64-v8a/libtor.so
grep: external/lib/arm64-v8a/libtor.so: binary file matches
grep: external/lib/arm64-v8a/libtor.so: binary file matches
grep: external/lib/arm64-v8a/libtor.so: binary file matches
grep: external/lib/arm64-v8a/libtor.so: binary file matches
grep: external/lib/arm64-v8a/libtor.so: binary file matches
grep: external/lib/arm64-v8a/libtor.so: binary file matches

However, when I try building with the newer NDK:

➜  a tor-android git:(master U:3 ✗) export ANDROID_NDK_HOME=~/Android/Sdk/ndk/29.0.13113456/
➜  a tor-android git:(master U:3 ✗) ./tor-droid-make.sh build -a arm64-v8a

I'm actually still able to grep these in libtor.so, though of course the binary I get doesn't actually work...

➜  a tor-android git:(master U:3 ✗) echo $ANDROID_NDK_HOME
/home/a/Android/Sdk/ndk/29.0.13113456/
➜  a tor-android git:(master U:3 ✗) grep Java_org_torproject_jni_TorService_createTorConfiguration external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_mainConfigurationSetCommandLine external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_mainConfigurationSetupControlSocket external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_mainConfigurationFree external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_apiGetProviderVersion external/lib/arm64-v8a/libtor.so
grep Java_org_torproject_jni_TorService_runMain external/lib/arm64-v8a/libtor.so
grep: external/lib/arm64-v8a/libtor.so: binary file matches
grep: external/lib/arm64-v8a/libtor.so: binary file matches
grep: external/lib/arm64-v8a/libtor.so: binary file matches
grep: external/lib/arm64-v8a/libtor.so: binary file matches
grep: external/lib/arm64-v8a/libtor.so: binary file matches
grep: external/lib/arm64-v8a/libtor.so: binary file matches

The devil is in the details, and the details seems to be to what happens with external/lib/arm64-v8a/libtor.so (or whatever abi...) after that file is created with the JNI symbols that we desire.

[bitmold]

In fact, I was able to get the library to build just fine with ndk 29.0.13113456 and use it with Orbot on an arm64-v8a device that I use for testing. I was having problems with a simulated x86_64 using this NDK last night though...

[syphyr]

I wish I understood why the symbols are not stripped out with your build.

[syphyr]

@bitmold can you please try a release build to see if the jni symbols are still included? The only difference I see is you are building debug and I am building release.

[bitmold]

I'll post my results next time I have a bit of time to lock in on this...

[syphyr]

I just tested building a debug variant with NDK 27.2.12479018 and the jni symbols were still stripped out.

[syphyr]

I just noticed that if I remove --strip-unneeded from the Makefile, then all the jni symbols are no longer stipped out of libtor.so. Although, even though they are no longer stipped out, I still get the following error when I use that with Orbot.

05-25 22:37:06.708  2090  2129 E AndroidRuntime: FATAL EXCEPTION: tor
05-25 22:37:06.708  2090  2129 E AndroidRuntime: Process: org.torproject.android, PID: 2090
05-25 22:37:06.708  2090  2129 E AndroidRuntime: java.lang.UnsatisfiedLinkError: No implementation found for void org.torproject.jni.TorService.mainConfigurationFree() (tried Java_org_torproject_jni_TorService_mainConfigurationFree and Java_org_torproject_jni_TorService_mainConfigurationFree__)
05-25 22:37:06.708  2090  2129 E AndroidRuntime: 	at org.torproject.jni.TorService.mainConfigurationFree(Native Method)
05-25 22:37:06.708  2090  2129 E AndroidRuntime: 	at org.torproject.jni.TorService.-$$Nest$mmainConfigurationFree(TorService.java)
05-25 22:37:06.708  2090  2129 E AndroidRuntime: 	at org.torproject.jni.TorService$3.run(TorService.java:383)

[bitmold]

Closing this outdated PR. Fixing this since it pertains to https://github.com/guardianproject/orbot-android/issues/1361