Writing Android NDK Code with Elements

Blog
21

I was hoping to see the full solution. How does the Android SDK project use this, via project references? does the binary end jp in the /JNI/<architecture> subfolder of the Android project and does it get packaged up into the .apk correctly? Can I see the (verbose) build log?

There’s many variables here, and it’s hard to diagnose without seeing the full picture. the @JNIExport itself looks fine as far as I can tell.

22

The binary lies in jniLibs/armeabi-v7a and ends up nicely packed into .apk
I attached my dummy Android Studio project for you to see the whole picture.
NDKLib.zip (1.3 MB)

23

Ah, the SDK project isn’t built in Elements, I see. All looks good as far as I can tell, I’ll need to have one f my colleagues to have a look at a lower level at why the method might not be exported correctly, then…

25

I also tried creating and building Android project with Elements. It didn’t work either.

26

Same error? that’d point to indeed there ing an issue with there export (or it’s name), then.

27

Yes, the same “No implementation found…” error.

2 Likes
28

Hi,

this looks like a recent regression in one of the underlying libraries we use. i’ll try to get a fix in for this early next week.

1 Like
29

Thanks, logged as bugs://80124

30

One more thing.
Not sure if it’s relevant, but 10 lines of code results in ~2.4Mb *.so library, which is kinda a lot.

31

that’s probably with Debug symbols, and optimization off, right?

also keep in mind that there are certain base libraries (some optional, like Elements RTL, some not like the core Island RTL and the GC) that add to the snake size, but are of course a one-time “cost” that seems large for 10 lines, but relativates itself as the project grows…

32

Yeah, optimizations are off, and it’s 0.5Mb less when it’s on.
Thanks for the explanation Marc.
Looking forward to that fix next week.

1 Like
33

bugs://80124 got closed with status fixed.

34

This is fixed for the next build. Do you have access to the betas?

35

No, but I just figured out that the build with version 10.0.0.2265 works fine. Thanks

36

Are there any known problems with this in the latest stable release (10.0.0.2373)? It appears to have regressed again (Android 8), the same “No implementation found…” error.

Additionally, with the arm64-v8a target on Android 8 another error:

java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "__data_start"

I’ll work on getting you a minimally reproducible example, but perhaps a notion might be to have a “known-good” Android NDK Extension example project on GitHub so that people might try to build that, making it easier to distinguish user error from regression.

37

Here’s some more salient details about the __data_start issue with the arm64-v8a target:

$ nm Bin/Debug/Android/arm64-v8a/*.so | fgrep __data_start
                 U __data_start

$ nm Bin/Debug/Android/armeabi-v7a/*.so | fgrep __data_start
         w __data_start

$ nm Bin/Debug/Android/x86/*.so | fgrep __data_start
         w __data_start

$ nm Bin/Debug/Android/x86_64/*.so | fgrep __data_start
                 w __data_start

This problem should be readily reproducible, I imagine, with a simple HelloFromNDK example.

38

hrmm that’s quite odd. I think updating llvm broke that. __data_start should point to the start of the data segment, and not be an actual token. I’ll investigate. Sorry for the convenience.

1 Like
39

Thanks, logged as bugs://82131

1 Like
40

Thanks for the replies. Did you guys figure this problem out, by any chance? (This is a blocker for my evaluation of the product.)

41

Arto,

I’m afraid this has to wait until next week (or possibly this coming Friday), because Carlo, who’s area of expertise this is, is on leave past and this week. I apologize for the inconvenience; we can of course extend you evaluation period once we have a fix out.

thanx,
marc