AndroidGithubBoss: a hand-collected ranking of Android open source work

A document, not a program

The repository contains exactly three things: a .gitignore, a LICENSE file and a README.md. There is no application, no script, no dataset file and no build. The project is a curated list, and the README is the artefact.

The stated origin is a personal impulse. The author writes that many developers do open source work in the Android world, that most people have no way of knowing who they are, and that he opened a project to gather those developers together, so that people can meet them and see their excellent open source work as material to learn from and refer to.

That framing matters for how you read the rest. This is not a service that stays current by itself. The README describes the collection as personal and voluntary, with the data gathered by hand, and it says the whole process took nearly half a year. The title says the list is updated irregularly, which is an unusually honest headline for a repository that could easily have claimed to be a live ranking.

So the value is the curation itself, which is a kind of work that a script cannot do, since the judgment of which three projects represent a developer's work, and which of those are worth reading, is the entire content.

Five columns, and what each one actually holds

The table has five columns. The first is a rank, running from 1 upwards. The second is a region, and the values are countries, with one entry recorded as unknown. The third is the GitHub username, shown with an avatar image and a link. The fourth is a personal homepage, and the fifth is a list of recommended open source projects.

The columns are where the interesting engineering decisions are, because each one is populated with a different kind of embedding. The avatar is a direct image from the GitHub avatar service keyed on the user id. The personal homepage column is not a link to a personal site at all, it is a rendered card from a github-readme-stats deployment on Vercel, generated per username with a query parameter. The project entries carry a link to the repository and a star-count badge.

So a row in this table is a small composition of external services rather than a piece of stored data, and the README is the only place the composition exists. That has a practical consequence for anyone who wants to reuse the list, since the renderings will break when a third-party service changes its URL scheme or disappears, and there is nothing in the repository to regenerate them from.

Deprecation badges on most of the recommended projects

The most striking detail in the visible rows is how many of the recommended projects carry a deprecated badge next to their star count. JakeWharton's butterknife, ViewPagerIndicator and timber all carry it. wasabeef's awesome-android-ui, recyclerview-animators and glide-transformations carry it. amitshekhariitbhu's android-interview-questions, Android-Debug-Database and from-java-to-kotlin carry it. daimajia's AndroidSwipeLayout, AndroidViewAnimations and NumberProgressBar carry it, and so do several of hongyangAndroid's entries, including okhttputils and AndroidAutoLayout.

The badge is a static shield in the Markdown, not a computed status, so it is a snapshot of what the author recorded while collecting. By contrast, skydoves' Balloon and Pokedex entries show no deprecated badge, though android-developer-roadmap does, and skylot's jadx entry shows only the star count.

The honest reading is that the list was assembled in an earlier era of Android development, when many of the most popular libraries were still the ones people used, and that a good number of them have since been superseded or retired. That does not make the list worthless. A library that is deprecated is often still the clearest example of a technique, and knowing who wrote it and where it came from is exactly what the author set out to collect. It does mean the badges are historical rather than current, and that a reader should check the current state of any project before recommending it.

How the data was collected and how to fix it

The README is explicit about the method. The author says the data comes from purely manual collection, that the whole process took nearly half a year, and that it is offered for reference, with omissions to be reported and errors to be reported as well, both through a new issue on the repository.

So the correction path is an issue, and only an issue. There is no script to regenerate the table, no JSON file to edit and no contribution flow for the list itself. That is a deliberate consequence of the design, since the list is the product and the product is a judgment about people, which is hard to automate and easy to argue with.

The visible rows also make the collection criteria implicit rather than stated. A name appears if the author judged the person to be a significant Android open source contributor, and the three projects are the ones worth studying. The region column records where the person is, which is the kind of field that is straightforward to misattribute and is exactly the kind of thing an issue is for.

The README's closing request, to submit pull requests for bugfixes, optimizations, documentation corrections and clarifications, applies to the repository as a repository. The list itself is a different kind of content, and the README asks for issues on it.

Everything visible depends on services the repository does not control

A list this small could have been a static table with plain links, and the fact that it is not is worth a second look. The avatars come from the GitHub avatar service with the numeric user id in the URL, the profile column is a card generated by a Vercel deployment of github-readme-stats, and the star counts are badges fetched from a badge service, each pointed at a specific repository.

That gives a README that looks alive and self-updating without any code in the repository. The cost is that the appearance of freshness is an illusion: the star count next to a project is fetched live by the badge service whenever the page renders, and if the README is the only file, there is no job in the repository that rewrites the table.

The same applies to the profile cards. They are generated per username at request time, so a username that no longer exists, or a card service that changes its deployment, changes what the table shows without anyone touching the repository.

For a reader this is mostly harmless and rather pleasant. For anyone who wants to fork the list and maintain it, it is a design decision that has to be reversed first, because a fork with the same embeds inherits the same staleness.

Where this list is the wrong tool

The first wrong-tool case is deciding who is influential. The ranking has no stated methodology, and the README describes a personal, manual collection rather than a metric. Rank 1 and rank 2 are separated by nothing more than the author's judgement, and the visible projects in each row are not comparable in popularity, scope or age. A list whose numbers do not encode a measurement is a reading list with an ordering, not a leaderboard.

The second is discovering current work. Because the collection is manual, dated and irregularly updated, and because many of the recommended projects now carry deprecation badges, the list is a snapshot of a period rather than a view of the present. Someone looking for what to use today needs a different source, and someone looking for a project to read is served well.

The third is any automated use. There is no dataset, no API, no export and no machine-readable ranking, and the only structured artifact is a Markdown table whose cells are HTML fragments. A team that wants a queryable list of Android projects by licence, language or maintenance status cannot get it from here without writing the extraction, and given the badges and the embedded images, that extraction is more work than it looks.

Apache-2.0, no releases, and a push in late June 2026

The project is licensed under the Apache License 2.0, with the LICENSE file at the repository root. That is a permissive grant, which fits a document that people are expected to read, copy and pass on, and it is the right choice for a list whose whole purpose is to point at other people's work.

The repository has no GitHub releases, which is unsurprising for a README-only project, and the primary language is recorded as unknown, since the content is prose in Chinese with HTML and Markdown rather than code in any language. The default branch is main.

The repository is not archived, and the last push was on 2026-06-30, a little under four months before this review. That is consistent with the README's own description of the list as updated irregularly, and it means the content is not frozen, just slow.

What the project is, in the end, is a favour. Somebody spent half a year writing down who they thought mattered in Android open source, along with the three projects each of them would want a newcomer to read, and published it in a place where anyone can improve it through an issue. The technology involved is a set of badge URLs, and that is not a criticism.

Editorial conclusion

Adopt AndroidGithubBoss as a reading list and a starting point for exploring Android open source work, and treat the ranking order itself as decorative rather than authoritative, since the entries were collected by hand and the table shows no scoring method. Do not build a curation pipeline on it, since there is no code to run, and do not read the deprecation badges as a statement about the developers, since they mark individual projects that have moved on. Before you rely on the list, check the profile cards yourself, because they are rendered by an external service, and file an issue through the repository when an entry is missing or wrong, which is the correction path the README asks for.

Frequently asked questions

Official sources

1. getActivity/AndroidGithubBoss on GitHub
2. Issues
3. License: Apache-2.0
4. README