Add Android Bionic support so SwiftNetwork builds on the Android SDK.

[Cartisim]

Motivation

os(Android) is not os(Linux). Swift on Android uses Bionic (import Android), so the existing Glibc / Musl Linux path does not compile as-is.

This change teaches SwiftNetwork that platform with the smallest possible delta: reuse the Linux system layer, import Android where Glibc was required, and paper over the few Bionic ABI differences the compiler actually hits.

Darwin behavior is unchanged.

Modifications

• Enable Logging and SwiftNetworkLinuxShim for .android in Package.swift.
• Compile the Linux system / netlink path as os(Linux) || os(Android).
• Import Android in sources that already imported Glibc.
• Gate Darwin-only files with canImport(Darwin) so they are not built for Android.
• Wrap Bionic’s variadic ioctl as SwiftNetworkLinuxShim_ioctl (unavailable from Swift).
• Match Bionic nullability for recvmsg / sendmsg / if_nametoindex, and use in6_addr.in6_u.u6_addr32 for IPv6.
• Extend the Linux-only #ifs that fail to compile on Android (Logger.notice, errSecSuccess, QUIC session-state callbacks, CryptoKitMetaError).

No new Android-specific networking implementation is added.

Testing

• Built SwiftNetwork for aarch64-unknown-linux-android24.
• Ran the Android test suite. Existing Darwin / Linux interface assumptions (lo0 vs lo, MTU, interface type) still fail on Android and are not addressed here.
• Please also confirm Darwin and Linux still build.

[tfpauly]

Note the overlap with #222

[rpaulo]

@Cartisim could you please let us know if there's anything in this PR that is not in PR 222?

[finagolfin]

@Cartisim, this is strange, that we both submitted this within hours of each other. Since you say you didn't get all the tests passing, while I did in my pull linked above, do you mind if I get mine in first, then you can rebase off that and propose any differences that remain here? Most of our pulls is just adding Android imports, so won't be much left once that's in.

How did you build and test this exactly, natively on Android in the Termux app?

[Cartisim]

@Cartisim, this is strange, that we both submitted this within hours of each other. Since you say you didn't get all the tests passing, while I did in my pull linked above, do you mind if I get mine in first, then you can rebase off that and propose any differences that remain here? Most of our pulls is just adding Android imports, so won't be much left once that's in.

How did you build and test this exactly, natively on Android in the Termux app?

Yes that is interesting. Yeah if we pull yours in I can rebase and see if there is anything interesting. One thing I thing would be good is to bump swift-tools version and swift-collections to 1.7.1. since we are still in pre release.

My changes are pretty much bare minimum for the bumped collections and tools for Android support.

My tests are passing using skip android test.

Thank you

swift-network-evolution % skip checkup
[✓] Skip version 1.9.10 (= 1.9.10)
[✓] macOS version 27.0.1 (> 13.5.0)
[✓] macOS architecture: ARM
[✓] Swift version 6.4 (> 5.9.0)
[✓] Swiftly version 1.1.4 (> 1.0.0)
[✓] Xcode version 27.0 (> 15.0.0)
[✓] Xcode tools SDKs: 5
[✓] Homebrew version 7.0.7 (> 4.1.0)
[✓] Gradle version 9.7.1 (> 8.6.0)
[✓] Java version 26.0.2.1 (> 17.0.0)
[✓] Android Debug Bridge version 1.0.41 (> 1.0.40)
[✓] Android SDK version 37.0.1 (> 29.0.0)
[✓] Resolve dependencies (17.91s)
[✓] Build hello-skip (39.12s)
[✓] Test Swift (12.25s)
[✓] Test Kotlin (46.53s)
[✓] Check project schemes (6.6s)
[✓] Archive iOS ipa (7.53s)
[✓] Assemble HelloSkip-debug.ipa 171 KB
[✓] Verifying HelloSkip-debug.ipa: 171 KB
[✓] Assembling Android apk (61.78s)
[✓] Verify HelloSkip-debug.apk: 85.1 MB
[✓] Check Skip Updates: 1.9.13
[!] A new version is Skip (1.9.13) is available to update with: skip upgrade
[!] Skip 1.9.10 checkup with 1 warning

[rpaulo]

Dup of #222. Thanks for your contribution. I think the other PR includes pretty much all your changes and we had to pick one since they were opened roughly at the same time. If there's anything missing from #222, please open a separate PR.