Support 16KB pages size

[marcprux]

Just like @andriydruk did at readdle/swift-android-toolchain@dc50b08

[finagolfin]

I don't intend to ever support this new feature with my 6.1 releases, and hopefully we can switch to official releases after that, so best to file this upstream.

[marcprux]

I filed a PR for this at swiftlang/swift#81596

[finagolfin]

Depending on whether #221 works, I'll add this here.

[finagolfin]

Most libraries should now work with 1b95949, will close once the last few are modified.

[finagolfin]

With the recent 6.2 release, all bundles here are 16KB page-aligned.

[MihaelIsaev]

I've switched to the 6.2 release and am encountering an issue when launching the app on an Android Emulator with 16KB page size:

FATAL EXCEPTION: main
    Process: com.some.app, PID: 2779
    java.lang.UnsatisfiedLinkError: dlopen failed: "/data/app/~~0K2WnG4RLu3-5KL59-e7og==/com.some.app-k_D47KFQFRSMZ3KVQJK2kg==/base.apk!/lib/arm64-v8a/libandroid-spawn.so" failed to setup 16KiB App Compat
    at java.lang.Runtime.loadLibrary0(Runtime.java:1090)
    at java.lang.Runtime.loadLibrary0(Runtime.java:1012)
    at java.lang.System.loadLibrary(System.java:1765)
    at java.lang.Class.newInstance(Native Method)
    at android.app.AppComponentFactory.instantiateApplication(AppComponentFactory.java:76)
    at androidx.core.app.CoreComponentFactory.instantiateApplication(CoreComponentFactory.java:51)
    at android.app.Instrumentation.newApplication(Instrumentation.java:1347)
    at android.app.LoadedApk.makeApplicationInner(LoadedApk.java:1479)
    at android.app.LoadedApk.makeApplicationInner(LoadedApk.java:1411)
    at android.app.ActivityThread.handleBindApplication(ActivityThread.java:7790)
    at android.app.ActivityThread.-$$Nest$mhandleBindApplication(Unknown Source:0)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2546)
    at android.os.Handler.dispatchMessage(Handler.java:110)
    at android.os.Looper.loopOnce(Looper.java:248)
    at android.os.Looper.loop(Looper.java:338)
    at android.app.ActivityThread.main(ActivityThread.java:9067)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:593)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:932)

The app works fine on non-16KB emulators and physical devices. Is there a specific swift build flag needed to ensure the produced target's .so file is properly aligned for 16KB requirements?

[finagolfin]

No, the bundle libraries have to be built on the CI that way, no subsequent build flag when using the bundle can fix that. I just checked and you are right that libandroid-spawn.so alone from this 6.2 bundle is now unaligned, which I had missed, but I get that from the Termux package repository and don't build it myself.

Is there any reason you're still using this SDK for deployment and not the new SDK that we've been posting about on the Swift forum? That will soon be the official SDK upstream, and I plan to stop releasing SDKs here after that. I will look at fixing my 6.2 SDK bundle here in the coming weeks, but you're better off using those linked SDKs.

[MihaelIsaev]

Is there any reason you're still using this SDK

Well, I just delayed switching to the new SDK while yours was working fine.

The new SDK is missing the following files that are present in your bundle:

libandroid-execinfo.so
libandroid-spawn.so
libc++_shared.so
libcharset.so
libcrypto.so
libcurl.so
libiconv.so
liblzma.so
libnghttp2.so
libnghttp3.so
libssh2.so
libssl.so
libxml2.so
libz.so

Is it because the new SDK assumes these files aren't needed for Swift apps?

My app is trying to load libandroid-spawn.so for some reason... guess maybe it is related to linking in this SDK

[finagolfin]

Is it because the new SDK assumes these files aren't needed for Swift apps?

No, most of them aren't needed separately anymore with the upcoming official SDK because they're included elsewhere. libandroid-spawn is a backport of Bionic's posix_spawn wrapper to API 24, which is no longer needed because the official SDK will only support API 28 or later, when posix_spawn was added to Bionic. The rest you list should now be statically linked into libFoundation{Networking,XML}.so, try them out and let us know if we missed anything, as you just did with my bundle here. 😉

Since the upcoming official SDK builds everything from source itself, unlike my bundle here, we can always update it pretty quickly if anything goes wrong.

[MihaelIsaev]

Got it, thanks!

Trying to compile my app for the first time with the new official SDK and it fails with both https://github.com/PADL/AndroidLogging and https://github.com/PADL/AndroidLooper unfortunately:

Building for debugging...
[0/26] Write sources
In file included from 
.build/checkouts/AndroidLogging/Sources/CAndroidLogging/CAndroidLogging.cpp:1:
.build/checkouts/AndroidLogging/Sources/CAndroidLogging/include/CAndroidLogging.h:17:10: fatal error: 'android/log.h' file not found
   17 | #include <android/log.h>
      |          ^~~~~~~~~~~~~~~
1 error generated.
In file included from
.build/checkouts/AndroidLooper/Sources/CAndroidLooper/CAndroidLooper.cpp:17:
.build/checkouts/AndroidLooper/Sources/CAndroidLooper/include/CAndroidLooper.h:19:10: fatal error: 'android/looper.h' file not found
   19 | #include <android/looper.h>
      |          ^~~~~~~~~~~~~~~~~~
1 error generated.
[10/26] Compiling CAndroidLooper CAndroidLooper.cpp
[10/26] Compiling CAndroidLogging CAndroidLogging.cpp
In file included from
.build/checkouts/swift-system/Sources/CSystem/shims.c:12:
.build/checkouts/swift-system/Sources/CSystem/include/CSystemLinux.h:12:10: fatal error: 'sys/epoll.h' file not found
   12 | #include <sys/epoll.h>
      |          ^~~~~~~~~~~~~
[10/26] Compiling CSystem shims.c

Looks very very sad to me, don't know what to say. Both libs compiles fine with your SDK.
This could be the answer why not to switch to the official one. But I have to since 16KB page size doesn't work in your SDK.
In the new SDK it seems now I have to execute setup-android-sdk.sh... can't say that it is amazing UX. Your SDK is perfect because it just works out of the box, as it should, no extra steps.

[finagolfin]

Trying to compile my app for the first time with the new official SDK and it fails

Did you follow the instructions there exactly, including running the setup-android-sdk.sh script to link the NDK to the upcoming official SDK? It looks like you did not, as it cannot find NDK headers.

If you did, this may be a bug in the upcoming official SDK, we'll look into it.

In the new SDK it seems now I have to execute setup-android-sdk.sh... can't say that it is amazing UX. Your SDK is perfect because it just works out of the box, as it should, no extra steps.

I ship the Android NDK sysroot with my SDK bundle, so you don't have to download the NDK yourself, which we didn't want to do with the upcoming official SDK. It's only two more steps the first time you install an official Android SDK, ie download the NDK then run a command to link the two, don't think it's a big deal. 😺

[finagolfin]

Btw, I just tried cross-compiling those two PADL repos you linked with the upcoming official Android SDK, no problem. I'm guessing you either forgot to run the setup script or it gave you some error that something went wrong. I suggest you sdk remove it and start over.