Writing Android NDK Code with Elements

(marc hoffman) #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.

(Andrew Colburn) #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)

(marc hoffman) #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…

(Andrew Colburn) #25

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

(marc hoffman) #26

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

(Andrew Colburn) #27

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

(Carlo Kok) #28


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
(RemObjects) #29

Thanks, logged as bugs://80124

(Andrew Colburn) #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.

(marc hoffman) #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…

(Andrew Colburn) #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
(RemObjects) #33

bugs://80124 got closed with status fixed.

(Carlo Kok) #34

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

(Andrew Colburn) #35

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

(Arto Bendiken) #36

Are there any known problems with this in the latest stable release ( 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.

(Arto Bendiken) #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.

(Carlo Kok) #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
(RemObjects) #39

Thanks, logged as bugs://82131

1 Like
(Arto Bendiken) #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.)

(marc hoffman) #41


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.