Developing, building and publishing a successful Android SDK includes many important stages
Once Helppier is developing the Helppier SDK, today we are excited to share with our blog readers the stages to build and publish an Android SDK. The process of developing an Android SDK includes several stages, from idealizing, coming up with concepts, and defining and designing the application’s architecture to how the application will be built and how it will be distributed.
This article will be focused on the latter, building and distributing.
Android Libraries
Currently Android includes three libraries that allow developers to build their apps:
Apache Ant: Ant was released as a standalone project in 2000 after developers needed a build automation tool that fit the Java ecosystem better than Make did. Ant is an incredibly flexible tool that doesn’t specify any requirements regarding project structure or coding conventions. Despite being a simple tool, it’s hard to use as there isn’t a specified structure set. Initial versions of Ant did not include a built-in support for dependency management.
Apache Maven: Maven was created as a simplified version of Ant and it included strict conventions and built-in support for dependency management. As most of the development is done with the usage of build plugins, the processes are mostly standardized and thoroughly tested and vetted by the Open Source community with expectable outcomes.
Gradle: Gradle was built with a heavy focus on learning from the best of the current ecosystem and trying to mitigate the worst of the currently available tools. Alongside that, Gradle brought significant enhancements as it featured twice the speed of Maven.
Given the ease of use and the current level of integration with Android Studio, Helppier has decided to generate an Android Library built by Gradle.
How to publish an Android Library?
Publishing an Android Library can be performed through several ways:
Manual Delivery: The distribution can be performed manually through a host server delivering the available builds. The main problems with this approach are that the responsibility of maintainability and ensuring that the service is always up falls on each company and, more importantly, it does not allow for version control and updates have to be performed manually.
JitPack: JitPack behaves as a package repository for Android Projects and is, by far, the simplest publishing mechanism tool available in the market. Unfortunately, JitPack requires a paid service in order to publish Private Repositories.
JCenter: For a long time was one of the easiest tools to publish Open Source projects but closed in 2021 and currently only allows for Read Only Packages.
Maven Central: Maven Central behaves similarly to JitPack as it provides a CDN for the build artifacts generated but supports faster and safer software supply chain automation. Currently provided by Sonatype Nexus.
As most of these approaches provide version control, adding them as a project dependency is as easy as adding any other Android dependency, as long as the repository where the dependency is available is registered on the project configuration file.
Due to the concern for safety, version control, and private usage, Helppier has decided to select Sonatype’s Nextus as the Maven Central host for its build artifacts.
Thanks for reading, hope this article could be useful to your Android SDK development! 😊
If you want other tips on developing a Mobile SDK, please check our article series around the Helppier Mobile Development, where we are sharing many challenges and solutions found during this process!
