Android API/ABI support

[mihe]

I'm in the process of implementing the (long overdue) Android and iOS support for Godot Jolt, and I only just now noticed that there's a bit of a discrepancy with regards to the range of support for Android devices between Godot and Jolt.

I haven't done mobile development in well over a decade now, but assuming I've understood this correctly:

JoltPhysics/README.md

Line 91 in 5159331

* Android (tested on Android 10) x64/ARM64

JoltPhysics/Build/Android/UnitTests/build.gradle

Lines 10 to 15 in 5159331

	applicationId "com.joltphysics.unittests"
	minSdk 24
	targetSdk 33
	versionCode 1
	versionName "1.0"
	ndk.abiFilters 'arm64-v8a', 'x86_64'

... Jolt "only" supports ARM64 (arm64-v8a) and x64 ranging as far back as API level 24, meaning Android 7 (Nougat)?

Is there any particular reason why you chose not to support ARM32 (armeabi-v7a) and x86?

Similarly, is there a reason why the minimum API level couldn't go as far back as API level 21, meaning Android 5 (Lollipop)?

Godot itself seems to support all of that, but from what I can tell these are generally either obscure or fairly old devices, but at the same time I am also seeing mentions of things like phones released as late as 2018 that seemingly had ARM64 CPUs but ran a 32-bit Android, and who knows what else might be out there, so I'm a tiny bit interested in trying to support it.

I tried running a armeabi-v7a build of UnitTests (at 7df682e) on my ARM64 Android phone, which is supposed to be backwards-compatible with ARM32 as I understand it, and it seemed to fail with the following output:

===============================================================================
UnitTests/Math/Vec3Tests.cpp:263:
TEST SUITE: Vec3Tests
TEST CASE:  TestVec3Cast

UnitTests/Math/Vec3Tests.cpp:265: ERROR: CHECK( Vec3(1, 2, 3).ToInt() == UVec4(1, 2, 3, 3) ) is NOT correct!
                 values: CHECK( 1, 2, 3, 0 == 1, 2, 3, 3 )
UnitTests/Math/Vec3Tests.cpp:266: ERROR: CHECK( Vec3(1, 2, 3).ReinterpretAsInt() == UVec4(0x3f800000U, 0x40000000U, 0x40400000U, 0x40400000U) ) is NOT correct!
                 values: CHECK( 1065353216, 1073741824, 1077936128, 3366877056 == 1065353216, 1073741824, 1077936128, 1077936128 )
===============================================================================
[doctest] test cases:    396 |    395 passed | 1 failed | 0 skipped
[doctest] assertions: 276345 | 276343 passed | 2 failed |
[doctest] Status: FAILURE!

... which may or may not be related to the fact that I'm getting showered in warnings like these when I try to build a armeabi-v7a build of Godot Jolt (which otherwise runs just fine):

External/Source/jolt/Build/../Jolt/Geometry/ClosestPoint.h:481:1: warning: '#pragma float_control' is not supported on this target - ignored [-Wignored-pragmas]
JPH_PRECISE_MATH_OFF
^
External/Source/jolt/Build/../Jolt/Core/Core.h:508:4: note: expanded from macro 'JPH_PRECISE_MATH_OFF'
                        _Pragma("float_control(pop)")
                        ^
<scratch space>:75:2: note: expanded from here
 float_control(pop)
 ^

Similarly, I tried running an x86 build of UnitTests (again at 7df682e) through an x86 AVD, and it seemed to fail with the following output:

===============================================================================
UnitTests/ObjectStream/ObjectStreamTest.cpp:228:
TEST SUITE: ObjectStreamTest
TEST CASE:  TestObjectStreamLoadSaveBinary

UnitTests/ObjectStream/ObjectStreamTest.cpp:228: FATAL ERROR: test case CRASHED: SIGSEGV - Segmentation violation signal
===============================================================================
[doctest] test cases:   235 |   234 passed | 1 failed | 161 skipped
[doctest] assertions: 41804 | 41804 passed | 0 failed |
[doctest] Status: FAILURE!

Anyway, don't take this as a formal request for adding support for these or anything. I was mostly just curious what your thoughts are, and whether maybe you just hadn't considered supporting these before. If you feel it's not worth the hassle then I'll happily drop support for these as well and sleep like a baby. :)

[jrouwe]

Hello,

There's no real reason for not supporting this other than that I thought the 32-bit versions of Android didn't exist anymore. As for the API level, that was chosen fairly randomly too (I think I looked at a list of all Android versions with % of devices running that version and cut it off at a couple %) so I have no issues with making it lower.

The unit test errors seem to be easily fixable, I'll try to take a look at it tomorrow.

Jorrit.

[jrouwe]

I made the required changes in #739 but I was not able to reproduce the #pragma float_control warnings. Perhaps Android Studio hides these?

[mihe]

Perhaps Android Studio hides these?

I think you're probably right, but there's also something strange going on.

I do still see the warnings when building with Ninja for armeabi-v7a from Windows, but weirdly enough I'm not seeing them when building with Ninja from Linux (GitHub Actions), where everything seems to work just fine (example here). Either it's a toolchain issue, as GitHub Actions uses a slightly older NDK, or it's a host issue in some weird way. I don't see why the host platform should affect things when cross-compiling though.

I'll do some digging, but seeing as how GitHub Actions makes no mention of it I don't think it should be a showstopper.

[mihe]

I can confirm that it is indeed a toolchain issue. The latest NDK (26.1.10909125), which is based on LLVM 17, gives me the same warning on my Linux machine when building from command-line with Ninja, whereas the NDK that GitHub's Ubuntu 20.04 image uses by default (25.2.9519653), which is based on LLVM 14, does not seem to produce that warning.

I'm fine with sticking to 25.2.9519653 for now, but I assume this will become an issue later down the line.

[jrouwe]

Ok, I will upgrade and try to fix things.

[jrouwe]

Fixed in #741

[mihe]

Much appreciated!