Welcome to the 5th blog in the series of GSoC 2020 blogs.
This week I finally fixed the Null pointer exception which was the main blocker to gradle last few weeks. I managed to fix it by a patch. Turns out, the issue wasn’t in the library, It was in plexus.jar So I patched it out.
This means some functionality in gradle might will be unavailable. I will have to check which one. But that’s for a later day. Next up I refreshed eclipse-aether patch. The patch was originally for using jars from eclipse aether instead of aether. And later it was tweaked to use maven-resolver to get the same jars that were used to build maven sub-project. The build was failing because I had missed a couple of things while converting the patch from groovy to kts. I completed it, refreshed patch also failed because it had the outdated version of the jars required. I corrected the issue. But on doing that I got a new error where the pgp signs of the newer jars weren’t present with gradle for verification. So I had to dig up the pgp signatures of the original upstream maintainer and add them to metadata. This finally solved all the issues with eclipse-aether patch.
But gradle is still far from completion. I am getting a new error which looks related to Ivy. But I am yet to dive in more. I tried using newer Ivy jars but to no use Ivy 2.4.0 causes a FTBFS issue as seen previously. There’s actually a patch submitted upstream which we used in Gradle 4.4.1 in salsa. But the patch never got merged upstream (The commit doesn’t belong to any upstream branch) so I don’t know if it works for current version of Gradle. I will have to manually go through upstream commits using sublime merge or something similar.
On Kotlin side of things, Samyak Jain is making progress and he has fixed a cyclic dependency in Kotlin itself for a plugin that Kotlin ships with. If we get Kotlin uploaded soon then it will be easier for Gradle. Right now I am using a .deb of Kotlin which I got from the WIP version of Kotlin.
I had started on android-sdk side of things last week. The basic idea is to use one repository in salsa and always clone and use only required versions of upstream repositories. Instead of cloning them separately. This way the build process will be much similar to upstream and will be easier to maintain. Right now upgrading android-* packages is a tough job as there are literally hundreds of upstream tags and revisions and packages are distributed among many repositories. e.g: adb was earlier in system-core package but now it will be in platform-tools once upgraded. Now to make that upgrade in salsa, We will have to completely remove it from system-core and add it to updated platform-tools. And similar work is needed for many other packages like fastboot, mke2fs, etc. That is a lot of work and kinda difficult for maintainers. Having one repository on salsa for all the packages we need makes the job much easier. As the maintainer has to maintain only the debian/ folder and update the .install and control files as and when required, Instead of having to move entire piece of source from one repo to other.
Okay now comes the tricky part, which upstream version / tag to choose? Among thousands of tags and builds which one is the one that the upstream currently ships? And how do we keep track of which repo builds what binary/ We solve it by downloading Android Studio and installing it. SDK manager and Android-SDK also get installed along with all the platform-tools and things like adb, etc. The binaries obtained from Android studio have version number and the build number. Take a look:
theloudspeaker@android-test:~/Android/Sdk/platform-tools$ ./adb –version
Android Debug Bridge version 1.0.41
Installed as /home/theloudspeaker/Android/Sdk/platform-tools/adb
Notice the 6597393 at the end of the version number? That is the build number. So we can just go and download the artifacts from this CI build. That gives us the same binaries in platform-tools which the upstream ships with Android Studio. Thus we know what builds from platform-tools. Now, to see which branch / tag / commit to clone from upstream, we take a look at the repo.prop from the same CI build page. We get the exact commit hash to look for in the repo. We can go to that commit hash and check which branch / tag the commit resides on. In this case, “platform-tools-30.0.3” tag. This whole idea for using the CI artifacts was because Chirayu Desai brought this twitter thread into the chat.
Now that sorts the platform-tools part which we want to ship. Similarly we need source for build-tools. That we will see later. For now we will be updating sdk-platform-latest on salsa and use to build all the binaries which the upstream platform-tools builds.
So that’s it for this week. I will be diving deep into platform-tools and listing which repos on salsa will be replaced by the new platform-tools and also the Gradle Ivy issue.
Thanks for reading! See you in the next one!