Skip to content

Add Android Workgroup charter and membership list #925

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

Open
wants to merge 18 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions _data/android-workgroup/members.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
- name: Abe White
handle: aabewhite
github: aabewhite
affiliation:

- name: Andrew Druk
handle: andriydruk
github: andriydruk
affiliation:

- name: Finagolfin
handle: finagolfin
github: finagolfin
affiliation:

- name: Jason Foreman
handle: threeve
github: threeve
affiliation:

- name: Joannis Orlandos
handle: Joannis_Orlandos
github: Joannis
affiliation:

- name: Luke Howard
handle: lukeh
github: lhoward
affiliation:

- name: Marc Prud’hommeaux
handle: Marc_Prud_hommeaux
github: marcprux
affiliation:

- name: Robbert Brandsma
handle: obbut
github: obbut
affiliation:

- name: Saleem Abdulrasool
handle: compnerd
github: compnerd
affiliation:

2 changes: 2 additions & 0 deletions _data/navigation.yml
Original file line number Diff line number Diff line change
Expand Up @@ -139,6 +139,8 @@
url: /foundation-workgroup/
- title: Testing
url: /testing-workgroup/
- title: Android
url: /android-workgroup/
- section: Governance
- title: Code of Conduct
url: /code-of-conduct/
Expand Down
77 changes: 77 additions & 0 deletions android-workgroup/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
---
layout: page
title: Android Workgroup
---

The Android Workgroup is a team that promotes the use of Swift for developing Android applications.

## Charter

The main goal of the Android Workgroup is to add and maintain Android as an officially supported platform for the Swift language.

The Android Workgroup will:

* Coordinate the development of a reference Swift Android SDK
* Improve and maintain Android support for the official Swift distribution, eliminating the need for out-of-tree or downstream forks
Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Author

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Author

Choose a reason for hiding this comment

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

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

Copy link
Contributor

Choose a reason for hiding this comment

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

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

Copy link
Member

@finagolfin finagolfin Mar 14, 2025

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Author

Choose a reason for hiding this comment

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

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

Copy link
Contributor

Choose a reason for hiding this comment

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

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.

* Recommend enhancements to core Swift packages such as Foundation and Dispatch to work better with Android idioms
* Work with the PSG to officially define platform support levels generally, and then working towards achieving official support of a particular level for Android
* Determine the range of supported Android API levels and architectures for Swift integration
* Develop [continuous integration](https://www.swift.org/documentation/continuous-integration/) for the [main Swift repository](https://ci-external.swift.org/job/oss-swift-RA-linux-ubuntu-24.04-android-arm64/) that adds Android checks for pull requests
* Identify and recommend best practices for bridging between Swift and Android's Java SDK and packaging Swift libraries with Android apps
* Develop support for debugging Swift applications on Android
* Advise and assist with adding support for Android to various community Swift packages

## Communication

The Swift Android workgroup uses the [Swift Android forum](https://forums.swift.org/c/development/android) for general discussions. It can also be contacted privately by messaging [@android-workgroup](https://forums.swift.org/g/android-workgroup) on the Swift Forums.

If any significant decisions are reached during one of the workgroup’s regular meetings, a member will post about them in the Forums within one week. The outcome of each proposal review will be announced by its review manager in a separate thread dedicated to that proposal.

## Membership

Membership in the Android Workgroup is contribution-based and expected to evolve over time. Adding new members and removing inactive ones is subject to a vote by the existing members and requires unanimous agreement. Membership is limited to ten members in total to keep the group small enough to be effective. A cap of two members per company is in place to avoid over-representation.
Copy link
Contributor

Choose a reason for hiding this comment

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

I was under the impression that steering groups had membership limitations but workgroups were supposed to be open to anyone who wants to contribute to that area. @shahmishal or @al45tair, correct me if I'm wrong.

Copy link
Member

Choose a reason for hiding this comment

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

We discussed this on the call with Mishal a month ago. We simply copied this text from the similar SSWG and Testing workgroup charters, so I think we're fine with further discussion on how to structure this Android workgroup.

We thought some member limitation would be helpful for us too, since some of our work is similar to a steering group, but I don't think we've really hashed it out.

Copy link
Member

Choose a reason for hiding this comment

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

We’ve added this to the agenda item for the core team meeting next week. @compnerd or I will provide an update soon.


The Core Team selects one member of the workgroup as the chair. The chair has no special authority over the workgroup, but they are responsible for ensuring its smooth functioning, including by:

* organizing and leading regular meetings,
* ensuring that the workgroup communicates effectively with the community, and
* coordinating meetings between workgroup representatives and other Swift workgroups or teams when necessary.

If you would like to join the workgroup, send a message to [@android-workgroup](https://forums.swift.org/new-message?groupname=android-workgroup) on the Forums and you will be invited to the next available group meeting to discuss it more. See Community participation for examples of ways to contribute and demonstrate your interest to the group.

Workgroup members will try to make a decision independently by consensus whenever possible, and will raise issues to the Core Team when there are particular challenges with reaching consensus on significant decisions.

The current members of the Android Workgroup are:

{% assign people = site.data['android-workgroup'].members | sort: "name" %}
<ul>
{% for person in people %}
<li>{{ person.name }}
{%- if person.affiliation -%}
, {{ person.affiliation }}
{% endif %}
{% if person.handle %}
(<a href="https://forums.swift.org/u/{{person.handle}}/summary">@{{person.handle}}</a>)
{% endif %}
</li>
{% endfor %}
</ul>

## Meetings

The Android Workgroup meets biweekly on Wednesday at 2:00PM ET (US Eastern Time). The meetings take place in the weeks with the [odd week numbers](http://www.whatweekisit.org/).

Many workgroup meetings are meant for open discussion and any Swift community member may attend by sending a message to [@android-workgroup](https://forums.swift.org/new-message?groupname=testing-workgroup) beforehand to request an invite. Some meetings are reserved for private discussion by group members, for example to make a decision on a proposal under review.

## Community Participation

Everyone is welcome to contribute in the following ways:

* Participating in design discussions.
* Asking or answering questions on the forums.
* Reporting or triaging bugs.
* Submitting pull requests to any of the Android support library projects.
* Discuss ideas on the Swift Forums. You can create new topics in the [Android](https://forums.swift.org/c/development/android/115) category, or add the android tag to any topic.
* Develop new tools to aid the Android experience or improve existing ones.
* Provide feedback to the members of the Android Workgroup directly by sending a message to [@android-workgroup](https://forums.swift.org/new-message?groupname=android-workgroup) on the Forums. The workgroup chair brings outstanding issues and topics to the workgroup to discuss during regular meetings. The workgroup decides the actions for the issues.
* Join the Android Workgroup’s regular video meetings. Send a message to [@android-workgroup](https://forums.swift.org/new-message?groupname=android-workgroup) to request access, since calls are easier to manage when kept to a relatively small number of participants.
1 change: 1 addition & 0 deletions community/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,7 @@ Advancing the Swift programming language with a coherent, clear view of its evol
* __[Language](#language-steering-group)__ is a small group of experts that drive the Swift language forward in a coherent direction.
* __[Platforms](/platform-steering-group)__ is a small group of experts that enables the Swift language and its tools to be used in new environments.
* __Workgroups__
* __[Android](/android-workgroup)__ is a team that works on the use of Swift for developing Android applications.
* __[C++ Interoperability](/cxx-interop-workgroup)__ is a team that works on adding the support for the bidirectional interoperability between Swift and C++.
* __[Contributor Experience](/contributor-experience-workgroup)__ is a team that supports contributors to the Swift project, including contributions on the Swift Forums.
* __[Documentation](/documentation-workgroup)__ is a team that helps guide the documentation experience for Swift.
Expand Down