Add Android Workgroup charter and membership list

[marcprux]

Motivation:

From the discussion at https://forums.swift.org/t/swift-on-android-working-group/77780/25 and in messages with @al45tair, this PR adds the Android WG charter for review by the Core Team and eventual publication to swift.org.

Modifications:

• Add the charter document at android-workgroup/index.md
• Add _data/android-workgroup/members.yml listing the members
• Add a navigation entry to _data/navigation.yml

Result:

The Android Workgroup charter and membership will be published to swift.org

[marcprux]

CC: @aabewhite, @andriydruk, @finagolfin, @threeve, @Joannis, @lhoward, @marcprux, @Obbut, @compnerd

[finagolfin]

Is anybody actually doing this? I think in-tree support is pretty good now, with downstream mostly just applying a few patches, ie nobody is maintaining an actual fork to my knowledge.

[marcprux]

Agreed that I don't know of anyone currently doing this. This specific point was requested by the PSG. I suspect – and perhaps one of them might confirm – that the goal is for the official Android SDK to be sufficiently adaptable to multiple Android environments (smartphone, embedded, car, TV. etc.) so as to make it unnecessary for a fork to have be created to support such an environment.

[finagolfin]

As far as I know, nobody has ever tried Swift on anything other than Android smartphones, so if those other Android environments require more work, nobody has even started on that.

I suggest you change "forks" to "patches", as that more accurately characterizes where the Android platform support is today for the dominant smartphone usecase, ie nobody has needed a fork in awhile.

[marcprux]

I'd be happy to make that change. @al45tair, what do you think?

[etcwilde]

I can't go into detail, but Swift is in use on more than just Android smartphones.

[finagolfin]

My only point is that Android support is in pretty good shape now, such that no forks are needed. I currently have to modify only a handful of lines in the stdlib and corelibs to have a working trunk Android SDK against the oldest API allowed for Play Store updates, with a dozen or so more lines if I want to support really old Android APIs or libTesting, as that new test library was just added with Swift 6 and I just added it to my Android SDK bundle.

I don't think Android TV or other environments require much else, and if something exotic like certain embedded kiosks or whatever do, right now nobody has heard of public Swift forks for that. I think you have an incorrect impression of what other Android environments require because of your experience mostly with Darwin platforms, which may be more differentiated, as I've heard of people running broad tests for their natively-compiled, ie non-Java/JVM, code that worked well on smartphones subsequently on Android watches without a problem.

Literally nobody has suggested not accepting Android TV patches: what I said is that either nobody has tried that or AFAIK nobody has required a public fork for that yet.

This is just about keeping this line accurate and setting expectations: Android support currently requires a few patches to upstream, not a fork, at least that I know of.

[etcwilde]

Maybe I misunderstood. I was mostly responding to this comment which I interpreted as "we don't need to care about the other uses of Android":

As far as I know, nobody has ever tried Swift on anything other than Android smartphones, so if those other Android environments require more work, nobody has even started on that.

I put Swift 5.6 on the television and were some bus errors due to unaligned memory accesses in the runtime. I believe that most of them were patched by the time of the Swift 5.9 release. I don't know if anything new has slipped in since.

[finagolfin]

Oh, that's interesting, haven't heard too much about people trying other languages on Android TV, as I think they're more restrictive in what apps you can install there too.

My only point with this suggestion is that the Android support is in pretty good shape in trunk already and we take patches in quickly, so public forks haven't been needed, to my knowledge. I think I have a pretty good idea of where it's at, as I suspect I'm the only person in the world who's been regularly running most of the same Swift toolchain tests that are run on the official linux CI but natively on Android, ie the compiler validation suite plus all the corelibs tests up to the SwiftPM and sourcekit-lsp tests, on a monthly basis for most of the last six years (hopefully we can soon get them running more regularly on the official CI too, swiftlang/swift#79185).

Changing this line to say "patches" signals to interested readers/users how far along this port has already come, but of course, any further testing and support for more niche Android uses is welcome.

[marcprux]

I'm convinced. I've changed "forks" to "patches".

[al45tair]

I don't think it's hugely important whether it says "forks" or "patches"; the point is to make clear that Android support belongs in the main source tree, and not as some kind of side-project. i.e. it is explicitly a goal for this Working Group that the main Swift distribution has Android support.

[al45tair]

@etcwilde You should probably look over this also.