Skip to content

GSoC 2024. Gradle Build Server – support for Android projects#

This project aims to enhance Gradle Build Server project from Microsoft by integrating powerful Android Studio features. Bridging the build process gap between Android Studio and Gradle Build Server, will significantly improve the development experience for many Android developers using Text Editors/IDEs which utilize the Build Server Protocol (BSP).

Status#

Passed end-term evaluation with successful completion of composite build support, JAVA_HOME handling and Android support PRs all merged.

Goal#

  1. Add support for composite builds. (vscode-gradle issue #1435)
  2. Java Home detection and sending notification on incompatibility. (issue #75 & issue #76)
  3. Add Android support with resolution of Android Java projects.

Team#

Contributor#

Mentors#

Rationale#

As the popularity of Android development grows, the need for efficient build automation tools like the Gradle Build Server becomes increasingly important. However, current limitations in identifying and managing common Gradle functionalities used in Android projects within the server can hinder developer workflows. This project aims to bridge this gap by introducing functionalities specifically tailored to Android development.

Deliverables#

Composite-Build Support (vscode-gradle issue #1435)#

Status: Complete (Merged) 🟢

Pull Requests: #154, #160

Objectives:

Pre-requisites:

  • Understanding Gradle API and Gradle Tooling API

Implemented Features:

  • Took over some work already done by @Arthurm1 in PR#122, into PR#154.
  • Utilized build actions to retrieve source sets from composite build projects which allowed for dependency substitution.
  • Fixed language extension downcast issue in PR#160 which was breaking composite builds.
Supporting Diagrams: Without composite build support With composite build support

Improved Gradle Java Home Handling (issue #75 and issue #76)#

Status: Complete (Merged) 🟢

Pull Request: #165

Objectives:

  • Build the project with default configurations, if Java Home is incompatible try and find a suitable Java Home.
  • If incompatible Java Home is detected notify client of the incompatibility.

Implemented Features:

  • Probe build the project to find if default Java Home configuration is compatible.
  • In case of incompatibility try to find a compatible Java Home in the given order: 1. GradleJavaHome (Gradle Properties) 2. UserJavaHome (Retrieved from preferences)
  • If project's default Java Home was incompatible, notify client we switched to a different Java Home for compatibility.
  • Notify client, if the fallback logic couldn't find a compatible Java Home.
Supporting Diagrams: Java Home Handling

Android Java Project Support#

Status: Complete (Merged) 🟢

Pull Request: #173

Objectives:

  • Providing build targets for Android Java projects to the client

Pre-requisites:

  • Understanding the entire Android build process and changes to the Android Gradle Plugin.

Implemented Features:

  • Extracted Build Variants and their properties from Android projects via reflection.
  • Populated GradleSourceSet (build target model) with build variant properties.
  • Provided Android SDK components and R file via dependency modules of the build target.

Limitations:

  • Android generates a lot of intermediate sources such as AIDL, Render script, C/CPP, etc. Unfortunately AGP doesn't provide any APIs to retrieve these files. R.jar is one of these intermediate sources which is crucial for Android development so as a workaround I have retrieved the file using the process task for the build variant however, in some cases the task may not be registered during the sync in which case the dependency for R.jar is not provided. (Issue #181)
  • There various kinds of projects that come under Android development such as Application, Library, Instant App, Dynamic Modules, Android Test, etc. I have added support for the most commonly used projects - Application and Library but the current implementation may require further enhancements to support other kinds of projects. (Issue #182)
  • My implementation takes into account all configured build variants except the default test variants - test and androidTest. (Issue #183)
  • Android Components to be used by an Android project is configured via ANDROID_HOME environment variable. If the property doesn't exist then we are not providing the dependency. This implementation can be improved via fallback logic similar to what we did for JAVA_HOME in PR #165. (Issue #184)
Supporting Diagrams: Android Build Process Android SourceSet Building

Documentation:#

Status: Complete 🟢

All my code is properly documented with JavaDocs and developer documentation is available in the Gradle Build Server with the following contents:

  • Documentation for implemented functionalities (composite-build support, Java Home handling, Android Java project support).
  • Usage instructions and troubleshooting steps for the added functionalities.
  • Clear examples and diagrams to enhance understanding.

Unit and Integration Tests:#

Status: Complete 🟢

Within the Gradle Build Server I have added unit tests and integration tests to ensure the accuracy and reliability of the implemented functionalities.

  • testCompositeBuild1 and testCompositeBuild2 unit tests ensure all the source sets from the composite build test projects are retrieved and the build target dependencies are mapped properly.
  • testCompatibleDefaultJavaHomeProjectServer, testCompatibleUserJavaHomeProjectServer and testIncompatibleUserJavaHomeProjectServer integration tests ensures the robustness of Gradle Java Home handling logic in different scenarios:
    1. Default configuration is compatible
    2. Compatible JDK available in User Preferences
    3. No compatible JDK supplied by any mechanism
  • testGetJavaVersionFromFile, testGetJavaVersionFromFile_SimulatedException and testGetJavaVersionFromFile_NonExistentExecutable unit tests ensure the Java version is successfully extracted from the given JDK file while handling possible failure scenarios.
  • testIsCompatible_Valid, testIsCompatible_OldestInvalid and testIsCompatible_LatestInvalid unit tests ensures the reliability of the compatibility checks for different java versions.
  • testAndroidSourceSets unit test ensures all the source sets(converted from android build variants) are correctly retrieved from the model builder and all the module dependencies are present.
  • testAndroidBuildTargets integration test ensures the Android Components is added to the module dependency of the build targets.

Demos#

Mid-Term progress#

Collaboration and Learning#

Throughout the program I have collaborated with all of my mentors and gained invaluable insights into open source development - best practices, project management and contributions. They also helped me learn how to explore large project repositories for research.

My work on this project, significantly expanded my skill set, encompassing JSON-RPC, Language Server Protocol, Build Server Protocol, Gradle, Gradle API, Gradle Tooling API, AGP, testing methodologies and merging techniques with git. I successfully applied these learnings to produce the mentioned outcomes.

If anyone is interested to continue the work and bring further support for Android projects in Gradle Build Server then you can get started with the following issues mentioned in this comment:

You can view all Android support related issues here.

Post GSoC progress#

The following progress has been made after final evaluation for this GSoC project was complete.

1. Updated Gradle for Java vscode extension#

With #1594 in vscode-gradle, it can now extract classes.jar file from the given android library (.aar) file.

2. Android test variants recognition#

Recognizing default android test variants - test and androidTest with #194.