Community Contributions to the Android Studio Plugin

[mai93]

The README describes the current state of the locations of Android Studio and IntelliJ/CLion plugins source code and how changes are shared between them.

In the plugin SIG meetings, the request for a way to accept more community contributions in the Android Studio plugin was brought up multiple times. Currently, these contributions are looked at on a case-by-case basis, which is not scalable. We are opening this discussion to talk more about the possible options we have to improve this.

[mai93]

We can continue the discussion here: @idanakav @nkoroste

cc @ujohnny @jastice

[idanakav]

First things first, the focus here is Android Studio & Bazel. For plain JVM or other languages, we are in good hands (whether it’s the master branch or the new BSP plugin).

Every company I’m aware of has a fork of ASWB, which is far from ideal. The main reason for this, as Mai stated, is the challenge of getting external contributions merged into ASWB.

The way I see it, we have the following options:

• Add back Android support to the master branch (it was broken before and subsequently removed during the cleanup in Cleanup sdkcompat  #7224 ) and make it an official community plugin for ASWB. As long as we keep cherry-picking/merging changes from AOSP, this could be a viable path. The downsides here are dealing with publishing and the risk of the plugin becoming deprecated in the future in favor of BSP.
• Create a new fork based on AOSP, in this case, the community would have more freedom regarding what to merge and picking changes from AOSP will be less tricky. However, the downside is that the fork's upstream is a repo in AOSP, which introduces extra overhead to get it built.
• Be more permissive with external contributions in AOSP, to the point where the need for most forks is gone. While this is an easier path conceptually, it doesn’t seem realistic from Google’s perspective.
• Remain in the current state, where each organization manages its own fork.

The 1st and 2nd options seem the most viable in the long term. For the 1st option, some questions arise:

1. Are we okay with bringing ASWB support back to the master branch?
2. Do we have an estimate of the effort required to cherry-pick and merge changes from AOSP, given the current divergence? For example, AOSP no longer supports multiple versions (sdkcompat).
3. What should we do when IJWB is deprecated? Perhaps we could keep this repo as the ASWB community plugin?

[nkoroste]

Thanks for kicking this off Mai and great write up Idan!

I think the general problem is that ASwB support/experience got worse (not better as originally was advertised) for the external community with the shift to Google branch and then AOSP project. So the main question we need answer is how can we make it better?

From Idan's proposal, option 1 is the ideal case for the external community.

[mai93]

One concern I've regarding option 1 is that we do not have someone with experience in AS among the current maintainers of the master branch. So fixing issues and even reviewing the users PRs can be challenging.

[ujohnny]

Thanks @idanakav for the write-up, and my apologies for the delay in response here.

For quite a long time, I had an idea similar to option (1) in mind, but so far, there has been no interest from the community in joining the maintenance for Android Studio. So, we just discussed with @tpasternak whether we could find an Android Studio version maintainer and see if it could move forward.

On the other hand, speaking from JetBrains' perspective, there’s no request to maintain the aswb version here, and in #7224, we partially removed some aswb-related files. However, we were still looking forward to receiving changes from AOSP, and in #6965, we closed the gap by cherry-picking hundreds of commits. I also just submitted #7262, which documents part of the cherry-pick process from AOSP, as requested several times in SIG meetings.

So let me answer questions as they appear.

1. IMO as long as (a) we can get agreement from the CODEOWNERS, (b) introduce a new maintainer for the aswb part, and (c) agree with the maintainer to be a code owner for aswb, I have a feeling we have no obstacles—though we should also agree on how AOSP cherry-picks will be handled for the aswb part. So far, we have had no modifications (I hope this is a correct statement) to aswb, and it does not introduce many conflicts during merges, though @LeFrosch might comment further.

   Our goal is to spend as little time as possible on AOSP cherry-pick conflict resolution, so we can follow one of two paths:
   (1) In case of a merge conflict, inform the aswb maintainer and expect the conflict to be resolved in a reasonable time.
   (2) We can resolve conflicts, but we are not responsible for keeping the plugin working (i.e., aswb CI will have soft fail enabled, so CI failures won’t prevent ijwb/clwb changes from being merged).
   (3) Propose your own option here.

2. I'd kindly ask @LeFrosch to comment on the effort required. Though we recently reduced the scope of compatibility and it depends what you'd like to see in the list of compatible Android Studio versions. So far we basically don't know how incompatible mirror-goog-studio-main to Meerkat. And I guess Ladybug is even more.

3. As I understand it, there’s always the option to transfer this repo to bazel-contrib if neither Google nor JetBrains will be maintaining it.

Last week, @LeFrosch and I had a call with @idanakav, and we proposed that it might be worth trying to bring some sdkcompat changes for AS Meerkat Feature Drop and attempt to build aswb with 243 compats for the base and other parts.

I also set up #aswb-in-bazelbuild-intellij on bazelbuild.slack.com as a place where @LeFrosch, @sellophane, or I can answer some questions.

Regarding other options, I’d say everything is doable—even forking this repo, removing non-aswb-related files, and using the same tool (see #7262) to receive updates from AOSP.

[LeFrosch]

(1) So far I have been picking aswb changes too, to reduce merge conflicts in future. But I have never even tried to build the aswb part and there might be incompatibilities with our state of base or java.

I agree with @ujohnny, that we want to spend as little time as possible on AOSP picks. Since the plugins are basically hard forks at this point, there might be a point in time where they diverged too much for us to continue picking changes.

(2) With regards to compatibility, we can always introduce a dedicated sdkcompat folder in aswb, but I would like to keep base only compatible with a couple of latest versions (2-3). But overall it’s hard for me to comment on that matter, since I have no idea what platform versions android studio targets and how up to date it is.