[WIP] changes for Android JVM integration #144
Conversation
lhoward
changed the title
|
Let us know when ready to review; I see this included the |
|
New to Android and Kotlin, so still figuring out what is ignorable :) Shall fix. |
|
This is great! The changes to the common code are quite narrow, which is quite encouraging. |
lhoward
force-pushed
the
lhoward/android
branch
11 times, most recently
from
f5ccb57 to
7dc5372
Compare
|
|
||
| __attribute__((constructor)) static void JavaRuntime_init(void) { | ||
| JavaRuntime_dlhandle = dlopen("libnativehelper.so", RTLD_NOW | RTLD_GLOBAL); | ||
| JavaRuntime_dlhandle = dlopen("libnativehelper.so", RTLD_NOW | RTLD_LOCAL); |
There was a problem hiding this comment.
Question about this! Should we link the JavaRuntime target to libnativehelper.so when building for Android rather than doing the dlopen here?
There was a problem hiding this comment.
Hmm, I'd assumed this wasn't possible because the Android NDK only provides the .so, and typically on Linux ld will only find a versioned .so. But maybe this isn't the case on Android. I'll check and get back.
There was a problem hiding this comment.
Actually I may have that around the wrong way, you need the unversioned .so at ld time, and the versioned one at runtime. So yes, checking I can link against it now.
There was a problem hiding this comment.
OK, this is possible, but requires setting the NDK target to >=31:
.unsafeFlags(["--target=aarch64-unknown-linux-android31"], .when(platforms: [.android])),
Obviously I don't want to encode the target architecture, do you know offhand if this is surfaced?
There was a problem hiding this comment.
- Actually this is a bit harder than it seems, for reasons I'll explain in a comment later.
lhoward
force-pushed
the
lhoward/android
branch
7 times, most recently
from
0c75fa9 to
416b7f3
Compare
|
Regarding linking rather than dynamically loading |
lhoward
force-pushed
the
lhoward/android
branch
6 times, most recently
from
05481c7 to
44752ac
Compare
lhoward
force-pushed
the
lhoward/android
branch
8 times, most recently
from
75e4f11 to
3dd9326
Compare
lhoward
force-pushed
the
lhoward/android
branch
from
3dd9326 to
661a6e6
Compare
lhoward
force-pushed
the
lhoward/android
branch
from
661a6e6 to
fd6d79f
Compare
lhoward
force-pushed
the
lhoward/android
branch
4 times, most recently
from
860c902 to
8d4b671
Compare
|
My new 6.1 SDK bundle supports building against all Android APIs between 24-35, try it out and let me know how it works. |
lhoward
force-pushed
the
lhoward/android
branch
3 times, most recently
from
d6db74a to
79d7d0d
Compare
This is not a real fix, I suspect the real fix is to remove javaEnvironment as an instance variable on all platforms and always use the ambient environment (as the JNI specification clearly states the environment cannot be shared between threads). Works around: swiftlang#157
|
With #401 merged I'm going to close this one; We did merge some minimal support |
4 participants
Created this PR to track changes for Android JVM integration. WIP only, not ready for review.