drone: a package manager for Android Gradle dependencies

The problem, stated as a search-and-copy routine

drone describes itself as the missing library manager for Android developers, and the readme explains the motivation as a developer who was jealous of the Node.js community for their fast and reliable dependency managers, because it is so easy to write yarn add and a library is imported into the project. So the author made drone for Android.

The reasoning behind it is a specific routine rather than a general complaint. If you think about it there are like 50 libraries used in 95% of the apps, naming retrofit, rxjava, gson, picasso, robolectric and recyclerview-v7 among them. And every time you want to add one, say butterknife, you have to follow a fixed sequence: google butterknife, go to the readme, find the lines to copy, notice that butterknife has two dependencies, copy and paste into the Gradle file, and optionally, if it was not in jcenter, go to the main build Gradle and put in the custom URL.

That is six steps of which four are mechanical and one involves reading a page of prose to extract a snippet. drone collapses it.

drone add butterknife

And everything is done for you automatically, as the readme puts it.

The summary list is six claims: a fast way to add libraries, no need to search the web for that library, an intuitive tool, adding multiple dependencies with a one liner, automated dependency and package management, and automatic import of custom URLs such as JitPack.

That last claim is the one that distinguishes the tool from a search-and-replace script. A library published on JitPack rather than a standard repository needs a maven URL and a dependency block pointing at a specific commit, and getting that wrong is a classic time sink. A package definition in the hive can carry that URL, so the tool writes a build that resolves.

The primary language is JavaScript, the licence is MIT with the copyright held by Cesar Ferreira, the default branch is master, and the last push was on 2026-09-12. The recent releases are v1.7.5 from 2019-09-17 and v1.7.4 from 2019-07-17, and the package metadata carries the same 1.7.5 version.

The command set

The usage help in the readme lists the commands, and it is a complete inventory of what the tool does.

Usage

   $ drone <command> <params>

   $ drone install                            # Downloads the packages
   $ drone test <library>                     # Tests the library by fetching its version
   $ drone add <library> <module>             # Adds a dependency to a module
   $ drone remove <library> <module>          # Removes the dependency from a module
   $ drone info <library>                     # Retrieves the info for this package
   $ drone update                             # Get the latest packages
   $ drone list                               # List all of the packages
   $ drone stats                              # Get some stats regarding the hive
   $ drone hive                               # Opens the hive url
   $ drone open <library>                     # Opens the library's homepage
   $ drone search <library>                   # Searches for the 'library' in the hive

There are three ideas in that list worth pulling apart.

The first is that the packages are downloaded, not just referenced. The install command downloads the packages and the update command gets the latest ones, and the list command lists all of the packages. That is a real local cache, and it is why the tool is described as a package manager rather than a scaffolding helper. The trade is that you now have a local copy of package metadata to keep in sync, which is what update is for.

The second is that the module is an explicit argument. drone add takes a library and a module, and drone remove does the same, so the target Gradle module is named rather than guessed. For a multi-module project that matters, because the same library might belong in one module and not another.

The third is that the tool is a thin client for a shared index. There is a search command, an info command, a hive command that opens the hive URL, an open command that opens a library's homepage, and a stats command for the hive. The search-then-add flow is the intended one: you look up what is available, then add it.

There is also a test command, drone test, which tests the library by fetching its version. That is a way of checking that a package definition resolves before you commit to adding it, and it is the sort of command that exists because the author hit a case where the definition was stale.

The readme gives a simple usage form, drone add with a library and a module, and then a single library example and a multiple example, with the multiple case being the one that shows the one liner claim: you can add several libraries to a module in one invocation, with picasso, retrofit, rxjava and gson as the example set.

The hive, and why it is a community repository

The most interesting design decision in the project is where the package data lives.

Instead of maintaining a server with all the possible libraries, the author went with a brew approach: the community will create a library once and it will be available to everyone else forever in the hive, which is a separate GitHub repository.

So the model is a git repository of package definitions, one JSON file per library named after it. The instructions are to follow the instructions to create the <library>.json file and then open a pull request in the hive. Adding a library to the ecosystem is a pull request, and the result is a shared, versioned, forkable index rather than an API someone has to keep running.

That has obvious advantages. The index is auditable, it has history, it can be forked, and there is no single operator who can take it away. The cost is that a package exists only if somebody has written one, and that the data ages with the ecosystem rather than being refreshed by a service.

That second point is the significant one for anyone evaluating the tool now. The readme's own workflow mentions jcenter, and the ecosystem reference in the package data format is built around how libraries were distributed at the time. The hive was populated when the tool was actively released, and the last release was in 2019, so the index describes a period of Android development that has since been superseded by Google's own repository changes and by the wider move to version catalogs.

The dependencies in the package metadata also tell you about the implementation. There is fs-extra and jsonfile for file handling, inquirer for the interactive prompts, meow for the command line parsing, chalk for the coloured output, json-colorz for the coloured JSON, shelljs for running the Gradle and Git commands, node-read-url for fetching remote resources, opn for opening a browser, homedir for the home directory, filehound and find-in-files for searching the project, match-bracket for working out the build.gradle structure, string-search for text matching, xml2js for parsing Android manifests and other XML, mz for the promise-based filesystem calls, update-notifier for the version check, github-project-inspector for repository metadata, and analytics-node for usage analytics.

The presence of analytics-node is worth noting, because it means the tool reports usage somewhere, and that is a fact you may want to know before installing it on a work machine.

How the project is built and where it stands

The repository layout is a small Node project with a clear split between the CLI entry point and the implementation.

There is cli.js at the top level as the executable, wired to the bin entry named drone in the package metadata, and the start script runs node cli.js. There is a src/ directory for the implementation, a test.js file run by the test script, an eslintrc.json with the lint script pointing at src, a yarn.lock, a.travis.yml for CI, and a docs/ directory plus extras/ holding the logo and the animated GIF used in the readme.

The stale.yml file at the top level is a distinctive touch. That filename is the format used by the stale bot on GitHub, which marks issues and pull requests as stale after a period of inactivity. Keeping a stale.yml in the repository is how a project controls that behaviour, and it is the kind of small thing that tells you the maintainer cared about the repository's tidiness rather than only the tool.

The dev dependencies are minimal, eslint at an older major version and xo, which is the opinionated style linter that was popular in the Node ecosystem at the time. The lint script runs eslint rather than xo, which suggests the two are used for different purposes or that the migration was incomplete.

The current state is the part to weigh. The last push was on 2026-09-12, so the repository is not abandoned, and the readme's own text is written in a way that suggests a maintainer who still puts the effort in. But the newest release is v1.7.5 from September 2019, seven years before the last push, and the dependency list pins versions from that period: chalk at 2, fs-extra at 4, inquirer at 3, meow at 3, update-notifier at 2, shelljs at 0.7 and mz at 2.

That matters more for a CLI than for a library, because a CLI is installed globally and run on a developer's machine with a modern Node and a modern npm. An install of drone today pulls a tree of packages that are several major versions behind, several of which have had security fixes since.

So the tool is a good idea with a well-chosen architecture, and the architecture depends on a package index that was assembled for a repository ecosystem that has since changed. The honest read is that it is more useful as a reference implementation of how to structure a community package index for Gradle than as something to install on a new project.

The single library case, and what the tool does with a module

The simplest usage form in the readme is drone add with a library and a module, and the single library example is drone add picasso app.

So the module is part of the command line rather than something inferred. In a typical Android project the Gradle setup has an app module and possibly library modules, and a dependency often belongs in one and not the other: a networking library in the data layer module, a test helper in the test module, a UI library in the feature module. Naming the module at the command line makes the intent explicit and avoids the tool guessing from a file it happens to find first.

The multiple case is where the one liner claim earns its keep, and the readme's example adds picasso, retrofit, rxjava and gson to a module in a single invocation.

The form in the readme uses backticks around each name, and the readme's own example in the usage help writes the same thing without them, as drone add retrofit app.

The other direction is drone remove, which takes the same library and module pair, and there is a short alias in the usage examples, drone rm retrofit app. Removing is the operation people forget to want until a dependency has caused a build problem, so you do not have to find and delete the block by hand.

Two of the remaining commands are about finding things rather than changing them. drone search rxjava searches the hive for a library, and drone info picasso shows the info for a package. Since a library is only usable by this tool if somebody has written a definition for it, the search command is the step that determines whether the tool can help you at all with a given library, and running it first is the sensible order.

The hive command opens the hive URL in a browser, which is the escape hatch: if the tool does not have a package, you can go and create one, and the readme's instructions cover writing the <library>.json file and opening a pull request against the hive repository.

Editorial conclusion

drone fits an Android developer who wants one command to add a library and its transitive dependencies without reading the library's readme, and it does not fit a modern project, because its hive was built around jcenter and the ecosystem has since moved, and because the last release is v1.7.5 from 2019. Before adopting it, check whether the library you need has a definition in the hive, because a package only exists there if somebody has contributed one, and verify the generated Gradle block against your own build conventions.

Frequently asked questions

Official sources

1. cesarferreira/drone on GitHub
2. License: MIT
3. Project website
4. README
5. Releases