Android SDK Tools consist of components of the Android platform used by app builders to develop, test, bundle and publish Android applications.
Linux is a choice platform for android developers, the need to have all the Android Platform components natively available in Linux cannot be overemphasized. Making these Android Platform components natively available in Debian will enhance developer productivity and simplify Android development environment setup, saving developers a ton of challenges they experience trying to install or update specific Android development tools of interest. Already much work has been done to package a handful of these Android Platform Components for Debian. My internship is centered on working assiduously to package the remaining Android Platform components for Debian.
Scope of the Project
The scope of the project is quite vast. Some of these components to be packaged depend on other components or Android libraries that are not yet packaged for Debian, in such case the later has to be packaged too or patches are created to use Debian substitutes of such dependencies. To successfully author such patches, good understanding of Android, Java, and the architecture of Java packages is paramount. Also, most of these components use different build systems and domain specific languages ( DSLs ) in their build scripts. Thus a good understanding of build systems such as Gradle, Maven, Bazel, and different DSLs such as Groovy and Kotlin is needed. Most of the time, it's helpful to adapt the build to utilize Debian-specific Java build workflow and helpers. This adaptation requires clear understanding of Java/Android build systems, and Debian Java build automation scripts and helpers. One of the most important of such Debian package build scripts is the rules file. Just as the name goes, the rules file is basically a bunch of make rules. Names of some of these rules are pre-defined, and will be called by the Debhelper or Javahelper package during build. To work efficiently with these rules, a good understanding of GNU Make is indispensable.
As a result of these, my Summer of Code experience has been more of learning. I must say I love the mental challenge it brings.
Progress report
My mentors have done well to map the tasks into a number of issues under the Debian Android Tools Team repository. These issues range from simpler non-packaging tasks to packaging new Android Components from Google source, updating existing packages, and writing automation scripts to aid the Debian Android packaging workflow.
The first task I worked on, as part of my application-supporting contribution, was updating apktool package to the latest upstream stable release. Upon the commencement of the main GSOC program, I undertook the task to test for which tag Google builds apksigner with. This sounds simple but was quite intense as there are about 870 tags in total and about 100 revisions for each android version in the apksinger upstream repository. So I had to learn some bash scripting and write a simple script to automate the process of checking out each tag and building an apksig.jar from each tag, and diffing the resulting .jar against the official binary from google source. One of my mentors, cde, proofread and helped improved the script to a more efficient version. As I gradually improve in bash scripting skills, I intend to develop the script into a more robust solution that will well serve similar purposes in the future.
Armed with some sketchy insights from our investigations, cde attempted building some high priority tags, in upstream AOSP ( Android Open Source Project ) and diffing the resulting binary against the official Google binary and the result was perfect for 12.0.0_r1 tag. Hence we know what tag to build the apksigner package from.
The next task I started was building a new package bundletool for Debian. Despite my familiarity with Debian packaging, this has unexpectedly been a tough one as it is my first ever new Java/Android package, and involves languages, APIs and build systems that are very new to me. It has been a mentally-challenging rollercoaster of learning and researching for me. So far I've been able to establish the required dependencies and found the available Debian packages that satisfy them. I am modifying the build to use the more flexible Debian standard build tools like javahelper and maven-repo-helper instead of gradle, so as to avert problems posed by Gradle-related dependencies like gradle-protobuf-plugin. Some of the dependencies such as zipflinger, which are neither available nor replaceable with existing Debian tools, have to be packaged for Debian.
Current work
Currently, I am working on packaging zipflinger, a dependency of bundletool, for Debian. I have also started work on updating apksigner package to the latest upstream version.
Once zipflinger is packaged, I will proceed with bundletool packaging by either patching in replacement codes for r8 ( or totally package it ) which is another dependency of bundletool not yet packaged.
Technologies learnt
- Bash scripting
- Debian Java packaging helper tools
- Java
- Android
- Groovy
- Kotlin
- Gradle
- Make
Going forward
Since debian/rules, arguably one of the most important scripts in Debian packaging, is written in GNU Make, I need to arm myself with good knowledge of GNU Make. At the moment and for the next few days I will be studying and practicing GNU Make, and how to write Makefiles while simultaneously making progress with zipflinger packaging.