Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] changes for Android JVM integration #144

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

lhoward
Copy link
Contributor

@lhoward lhoward commented Oct 31, 2024

Created this PR to track changes for Android JVM integration. WIP only, not ready for review.

@lhoward lhoward changed the title Draft PR: tracking changes for Android JVM integration [WIP] changes for Android JVM integration Oct 31, 2024
@ktoso
Copy link
Collaborator

ktoso commented Oct 31, 2024

Let us know when ready to review; I see this included the .idea folder, so please make sure to .gitignore that as well 👍

@lhoward
Copy link
Contributor Author

lhoward commented Oct 31, 2024

New to Android and Kotlin, so still figuring out what is ignorable :) Shall fix.

@DougGregor
Copy link
Member

This is great! The changes to the common code are quite narrow, which is quite encouraging.

@lhoward lhoward force-pushed the lhoward/android branch 11 times, most recently from f5ccb57 to 7dc5372 Compare November 5, 2024 00:15
@@ -34,7 +34,7 @@ static JavaRuntime_GetCreatedJavaVMs_fn JavaRuntime_GetCreatedJavaVMs;
static void *JavaRuntime_dlhandle;

__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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question about this! Should we link the JavaRuntime target to libnativehelper.so when building for Android rather than doing the dlopen here?

Copy link
Contributor Author

@lhoward lhoward Nov 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Actually this is a bit harder than it seems, for reasons I'll explain in a comment later.

@lhoward lhoward force-pushed the lhoward/android branch 7 times, most recently from 0c75fa9 to 416b7f3 Compare November 5, 2024 05:23
@lhoward
Copy link
Contributor Author

lhoward commented Nov 5, 2024

Regarding linking rather than dynamically loading libnativehelper.so, we'll need upstream Swift Android SDK support (finagolfin/swift-android-sdk#191) for building against arbitrary Android API levels. If we force the API level to one that includes libnativehelper.so then the Swift runtime libraries are not found.

@lhoward lhoward force-pushed the lhoward/android branch 6 times, most recently from 05481c7 to 44752ac Compare November 7, 2024 03:48
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants