forked from swiftlang/swift-docker
-
Notifications
You must be signed in to change notification settings - Fork 1
Android API 23 #16
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
Merged
Merged
Android API 23 #16
Changes from all commits
Commits
Show all changes
97 commits
Select commit
Hold shift + click to select a range
5f1dbac
Add Android workflow
marcprux 1b7e52f
Merge branch 'swiftlang:main' into main
marcprux c263e80
Merge branch 'swiftlang:main' into main
marcprux dd6d09f
Merge branch 'swiftlang:main' into main
marcprux 6565052
Build Android image (#1)
marcprux 5f9dab4
Merge branch 'swiftlang:main' into main
marcprux 412e6b0
Merge branch 'swiftlang:main' into main
marcprux 40733f7
Swift Android build 6.2 (#2)
marcprux 53e361a
Swift Android build 6.2 (#3)
marcprux 72964f5
Build SDK in Docker container (#4)
marcprux 9160168
Merge branch 'swiftlang:main' into main
marcprux 4987bcc
Checkout patches repo instead of using a git submodule
marcprux ff3f274
Update libcurl to 8.13.0
marcprux 595efc3
Remove resources that we no longer use
marcprux 27b1bf4
Update libcurl to 8.13.0
marcprux b898129
Update libxml2 to 2.14.2
marcprux f566b23
Build libxml2, libcurl, and boringssl with support for Android 16kb p…
marcprux 529e3f1
Add build-script --extra-cmake-options=-DCMAKE_EXTRA_LINK_FLAGS=-Wl,-…
marcprux c82587d
Add 16KB page size linker flags to linker flags in swift-toolset.json
marcprux 217f1d7
Add 16KB page size linker flags to linker flags in swift-toolset.json
marcprux 95046b3
Build with ndk-r28b
marcprux 8b18b5f
Revert to building with ndk-r27c
marcprux f67f9bf
Use official endpoints for discovering latest Swift release/devel/tru…
marcprux 7011a45
Typo fix in version script
marcprux 4c65a93
Cleanup for PR
marcprux d80c80b
Change BUILD_VERSION to BUILD_SCHEME and have it match release, swift…
marcprux 2c07eef
Update Android README
marcprux 51d93f8
Update how patches are applied
marcprux 46a06df
Fix source directory for patch target
marcprux afb2918
Harmonize timestamps in artifactbundle with the swift source tag date…
marcprux a469e85
Simplify toolchain-vars.sh
marcprux dea39d7
Merge branch 'swiftlang:main' into main
marcprux b3cddbd
Merge branch 'swiftlang:main' into main
marcprux abd3fd1
Merge branch 'swiftlang:main' into main
marcprux ad24ea5
Merge branch 'swiftlang:main' into main
marcprux 50ba1cd
Run the compiler validation suite for Android (#8)
marcprux 71b7131
Build compiler-validated bundles from latest branch commits, not olde…
finagolfin e2f696a
Merge pull request #9 from swift-android-sdk/Testing
finagolfin 3f4cd4a
gcpd 'Update patches'
marcprux bd0df11
Update patches and build matrix
marcprux 80291aa
Disable compiler validated builds on self-hosted
marcprux 18c563f
Centralize cmake variable for 6.2 in patches, as done for trunk upstream
finagolfin ed09034
Update disabled tests
finagolfin e4a96b2
Merge branch 'main' into update-patches2
marcprux f472e9e
Try running Docker build on macOS host
marcprux 22a4320
Remove separate checks of libxml2, curl, and yams
marcprux bc3f105
Merge pull request #11 from swift-android-sdk/update-patches2
marcprux a7b303a
Remove upstreamed 6.2 branch patches
finagolfin 4ed1375
Merge branch 'swiftlang:main' into main
marcprux 3f36409
Use command-line flags to work around CMake 3.30+ linker flag bug, ra…
finagolfin f658604
Create an Android CMake toolchain file instead to cross-compile Testi…
finagolfin c9fc3d8
Install the native host LLVM tools for full compiler builds
finagolfin b881e14
Extend `--cross-compile-build-swift-tools=False` to disable building …
finagolfin 9af1d90
Don't copy any libraries from the NDK: link the NDK's clang resource …
finagolfin 5693797
Wildcard the clang version link in the post-install script in order t…
marcprux 31f00b1
Merge pull request #13 from swift-android-sdk/clang-wildcard
marcprux db10f68
Merge branch 'swiftlang:main' into main
marcprux 1221544
Switch generated shell header to use #!/usr/bin/env bash
marcprux f555f48
SBOM and nits (#14)
marcprux 7696a44
Remove upstreamed patches and turn the last modifications into perl s…
finagolfin 606ab7a
Remove self-hosted build on github CI
finagolfin 8eb982e
Remove android_build job from pull_request workflow
marcprux 534175d
Add license headers to Android build scripts
marcprux d139654
Remove unnecessary .gitignore
marcprux 510addd
Add license header to Dockerfile
marcprux ee191ee
Merge branch 'swiftlang:main' into main
marcprux 87bf6a2
Switch over to using explicit tags and branches when invoking build-d…
finagolfin 9987e54
Merge branch 'swiftlang:main' into main
marcprux 110ab52
Merge branch 'swiftlang:main' into main
marcprux 811583e
Merge branch 'swiftlang:main' into main
marcprux 3070fba
Fix build script arguments to use false instead of False due to true_…
marcprux bd87b1a
Build swift-6.2-RELEASE
marcprux ead9ba9
Apply patch from https://github.com/swiftlang/swift/pull/84061 for 6.…
marcprux 1a19b03
Update patch application for 6.2
marcprux fab74d2
Change 6.2 to perform local build
marcprux d05b59d
Change 6.2 to perform local build on ubuntu-24.04
marcprux bf5d18d
Switch back to building 6.2 from a tag
marcprux 7f71402
Switch back to building 6.2 from a tag
marcprux 233b535
Switch back to building 6.2 from a tag
marcprux f8fcf04
Build the Swift 6.2 release self-hosted with compiler validation
marcprux 2e0a326
Set minimum Android API to 24
marcprux 865e13f
Build against swift-DEVELOPMENT-SNAPSHOT-2025-10-16-
marcprux 9d14a52
Disable building libxml2 tests to handle missing glob function in And…
marcprux d7c0884
Disable building libxml2 tests to handle missing glob function in And…
marcprux be7a646
Build this PR without compiler validation
marcprux 09839a9
Build this PR without compiler validation
marcprux 19adc6b
Disable posix_spawnattr_ for Android 24
marcprux 21c5b03
Reduce Android API from 24 to 23
marcprux 069b38c
Restore Android minimum API to 24
marcprux c30a475
Add swift-nio to tests cases being run
marcprux 8c6f92c
Reduce Android API from 24 to 23
marcprux f4aa58c
Try building swift-collections
marcprux b364c93
Try testing against emulator API level 23
marcprux 6083eb1
Fix backtrace call
marcprux 18e77e8
Fail with an error for posix_spawn
marcprux 65dae50
Fix error for posix_spawn
marcprux 6b12a06
Remove temporary swift-docker Android build workflow
marcprux File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you want to do with this pull, actually merge all these changes, that simply stub out newer API calls, to the official CI and SDK bundle generator or properly
#availablecheck them in their repos once you try this stubbed-out bundle here first?My bigger concern is who is going to maintain the SDK bundle for these older APIs in the coming years. If @etcwilde and @madsodgaard and whoever else wants us to ship an official bundle built against API 23, they should be willing to handle all issues stemming from APIs 23-27, since that primarily affects them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I mostly started this PR to see how hard it would be to get an SDK build that worked for API 23. I was surprised how little patching was needed. I hadn't developed any concrete plans beyond that.
Ideally, we'd hear from more people from the forum post on the topic, and especially whether this build might be suitable for @madsodgaard's work. If supporting back to API 23 would prevent the need for people to use their own custom builds of the SDK, then I think it would be worth it to get this in.
The question then would be whether to just go ahead with this PR (which merely disables things that aren't really applicable on Android anyway), or wait on being able to use
#available(Android, …)(which, from what I understand, would need to wait until we want to require NDK 28+ for Android development). Since we're already patching stuff, and since the patches are fairly harmless, I personally think it would be fine to merge this short-term. We could even say that we "officially" only support/recommend API 28+, and older targets likex86_64-unknown-linux-android23would be left to the developer to experiment with.WDYT, @finagolfin, @shahmishal, @madsodgaard, @grynspan, @andriydruk, @Joannis?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great for us, so that we don't have to fork our own SDK:) but as I mentioned on the forums, we would still need the shim for ifaddrs (to use networking like NIO) and probably also fix up the FILE pointer, for this to be usable for us. Other than that, it would be great.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not to be overly cantankerous, but an official Android toolchain really ought to be built from the official Swift sources. In other words, if there are changes needed in components of the Swift toolchain, we should get PRs up for as many of them as possible. If this is a stopgap until
#availableis, er, available, then can it wait a few weeks for that to happen?I realize the situation is different for Swift 6.2, but Swift 6.2 has shipped to developers already and changes to the Swift toolchain should probably focus on the next release (6.3) instead.
With regards to the Swift Testing patch specifically, it's a problem for us because it is fragile and means a change to our code could break Android without us having any signal. The code in question is shaped like:
But if we were to change the code such that Android came first, or such that we had
#errorinstead of#warning, now the toolchain would fail to build. I'm not anticipating those changes will actually happen, just trying to illustrate why I'm opposed to having the patch here.Anyway, that's my two cents.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand — and I don't disagree with — your objection, but do note that the potential
backtraceissue you mention is already in place with the current Swift SDK for Android release. This PR just shuffles the patch from the build-docker and build-local scripts into a single place in fetch-sources.sh (as well as implementing the additional patches).Not to be too cavalier, but if the build starts failing (either in the official CI or in my watchdog CI), either @finagolfin or I will know to address it. And if/when we are able to make
@swift-ci Please test Androidrequests, that will further enhance stability.The broader picture is that this PR widens the potential users of this SDK, which is something @shahmishal asked us to look into. The patching is meant to be temporary, and will be progressively removed as we either start relying on
#available(Android, …)or work around them withdlsymjiggery-pokery.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, I'm not trying to hold up the merge, just trying to get my thoughts out before I forget 'em all. :)
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, that is a good question: we may have to provide an SDK bundle ourselves that's built against the new stable NDK 29, as the next trunk tag may not work well with LTS NDK 27, now that Mads's
#availablepull was merged.We may have to use different NDKs for 6.3 and the upcoming 6.2 CI, as long as one has
#availableand the other doesn't, then decide if we want to push#availableinto 6.2 or not.@marcprux, since you're one of the few people building your own toolchain, want to try pushing the
#availablepull and NDK 29 into a release/6.2.1 bundle locally generated by the Docker script, then copy that modifiedswift-frontendit builds into your toolchain and test it? We're going to have to provide something like that in our quasi-official 6.2 releases next, so people can try out this new feature easily.No problem, I think we all agree on the principle, but as they say, the cantanker is in the details. 😉
In this case, I tried to upstream all the patches I could, but left only three in the final Docker script: a compiler test that we were seeing strange file permission errors with
git grepin our Docker runs alone, a modification ofbuild-scriptto work around aswift-driverregression for which I submitted a fix many months ago, and disablingbacktrace()for swift-testing. I think that is fine for a preview release that can't use Testing much anyway because of this long-standing SwiftPM bug, swiftlang/swift-package-manager#8094, which appears to break cross-compiling Testing with SwiftPM to all platforms, while the first two changes obviously only affect the build, not the produced SDK bundle.As for this change, I'm fine with it, as these APIs basically do nothing on any Android device, because the OS assigns a random temporary user to every Android app installed.
I do think we should investigate and remove the
git grepissue soon, and not simply stub out those laterposix_spawnAPIs if we want to get this in.