AnyChart/AnyChart-Android: charts for Android, distributed through JitPack

A JitPack coordinate, and no way to check the version history

The dependency you add is this:

dependencies {
        implementation 'com.github.AnyChart:AnyChart-Android:1.1.5'
}

That coordinate is the tell. There is no group id of the vendor's own and no Maven Central entry; it is a GitHub path with a version appended, which means the artefact is built on demand by JitPack from the repository rather than published by the author. The repository root contains a jitpack.yml to configure that build, and a badge in the README points at the JitPack build status. So the supply chain for this library is a third-party build service reading a public GitHub repository, and the version is the state of that repository at a JitPack build, not a released binary. What you cannot do is check what 1.1.5 contains. The repository has no GitHub releases, no tag list in the README, and no changelog, so there is no way to see what changed between 1.1.5 and any earlier version, or whether 1.1.5 is even the newest build. For a library that renders data in your application, that is an unusual amount of uncertainty to accept, and it is worth pinning the version rather than tracking a moving artefact, precisely because the version number is the only handle you have.

The repository block has to go in allprojects, and the README shouts about it

The installation section opens with a warning in capitals, and it is the right one. The JitPack repository must be added to every project in your Gradle build, not to the buildscript block:

allprojects {
        repositories {
                ...
                maven { url 'https://jitpack.io' }
        }
}

The failure mode when this is wrong is worth understanding rather than memorising. Add it under buildscript and Gradle has a working repository for plugin resolution, then fails to resolve the library itself, and the resulting error names the artefact rather than the misplacement. People spend an evening on it. Add it under allprojects and every module in the build can see JitPack, which is what a dependency added by a subproject needs. The second supported route is not Gradle at all. You can copy an AAR file into the libs folder of the application project, and the README then gives five steps for Android Studio: open Module Settings, add a new module with the plus button, choose the JAR or AAR import option, find the file, and add the new module as a dependency from the app module's dependencies tab. That route exists for projects that cannot add a repository, which is increasingly rare but not imaginary in restricted build environments. What the installation section covers in detail, then, is getting the artefact onto the classpath. It says nothing about what happens when you build a release.

The sample module has ProGuard rules and the install section does not

Look at the sample directory rather than the README for the integration cost. The sample module contains a build.gradle, a proguard-rules.pro, and a source tree with one Activity per chart type. The presence of a consumer-side ProGuard configuration in the sample is the most informative file in the repository, and the installation section never mentions it. It matters because a ProGuard or R8 configuration in a sample module is there for a reason: something in the library is discovered reflectively or generated at build time, and shrinking your app removes the names or members that the code looks up. Charts are exactly the kind of component that needs a resource or a class name resolved at runtime, often per series or per axis. So the practical consequence is that adding this library to a release build may produce an app that works in debug and crashes or renders blank after shrinking, and the fix is a set of keep rules that you have to find in the sample and adapt. That is an integration step with a real failure mode, and it belongs in an installation section rather than in a sample module. If you evaluate this library, copy the sample's ProGuard file into your project before you write any chart code, and test the release build early rather than at release time.

One Activity per chart is the actual documentation

The README's chart gallery is a table where every row links to two things: a sample app on Google Play under the package com.anychart.anychart, and a code snippet in the repository at a predictable path, such as sample/src/main/java/com/anychart/sample/charts/PieChartActivity.java. That convention is the documentation. Each chart type has its own Activity, so the learning path is to open the file for the chart you want and read one class. The types visible in the README include Pie, Column, Line, Venn, Radar, Tag Cloud, Heat Map, Waterfall and Tree Map, and the text says the family includes scores of chart types and that new ones are being added constantly. Two observations. First, the same one-Activity-per-chart pattern is how the AnyChart projects for other platforms are structured, which is visible in the logo alt text describing a JavaScript and HTML5 charting library for any project, so this Android port follows a house pattern rather than inventing one. That is a good sign for consistency across their samples and a caution about how much Android-specific guidance exists. Second, the Play Store sample app is genuinely useful in a way documentation is not: you can install it, tap through the chart types, and see interaction behaviour on a real device before deciding which ones you need. Do that before you write anything, because a Venn diagram and a heat map behave very differently under a finger.

Two loose shell scripts stand in for a CI configuration

The top level of the repository is where the maintenance story shows. There is a gradlew and gradlew.bat with a gradle directory, a build.gradle, settings.gradle and gradle.properties, and then two files with no extension: android-wait-for-emulator and run-instrumental-test. Both names are test infrastructure, and the second contains a misspelling of instrumented, which tells you they are hand-written helpers rather than something generated. There is no .github directory in the listing, so there are no GitHub Actions workflows. The implication is that instrumented tests, which need a running emulator, are driven by two ad hoc scripts at the repository root rather than by a configured pipeline. That is a legitimate choice for a library whose tests genuinely need hardware, and it is also a fragile one, because a script that waits for an emulator and a script that runs instrumented tests only work together in an environment somebody set up by hand. Combined with the absence of releases and the last push on 2026-03-13, the picture is of a mature library in maintenance mode rather than in development. That is a perfectly reasonable thing for a charting component to be, and it is also a fact you should weigh: you are depending on a library whose own verification you cannot observe and whose version history you cannot read.

API 19 support, an unrecorded licence, and a README that sells

Three things to weigh before choosing this over a modern Android chart library. The compatibility claim is API 19 and above, which is Android 4.4, and it is advertised with a badge linked to an API level reference. Supporting an operating system from 2013 is generous, and it is a genuine reason to pick a library, because most of the current alternatives state a much higher minimum. It also constrains the implementation, since modern graphics and animation APIs cannot be used without version checks. The second is the licence. The repository records no licence, which for a dependency you ship inside a commercial application is not a formality; the README links to a LICENSE badge for MIT elsewhere in its badge row, but the repository itself is recorded as having no identifiable licence, so read the terms before you ship. The third is the tone. The README calls the library amazing, promises dozens of built-in chart types, and says new ones are constantly being added. That is vendor language, and it carries no information you can act on. The facts you can act on are the coordinate, the API level, the sample structure, the ProGuard file, the two test scripts, and the absence of releases. Judge on those, and use the Play Store sample to decide whether the chart types are the ones you need. If they are, the library does the job; if your requirement is a signed, changelogged, observable dependency, this is not one.

Editorial conclusion

Adopt AnyChart-Android if you want interactive charts on old Android versions, because supporting API 19 is a real constraint that most modern Android chart libraries have dropped, and the sample module gives you a working Activity per chart type to copy. Do not adopt it without reading the source, because the licence is not recorded for the repository, the last push was 2026-03-13, and there are no GitHub releases, so the version in the README is the only version information you have. Two things to verify first. Add the JitPack repository under allprojects and not under buildscript, exactly as the README warns, or resolution fails in a way that looks like a missing artefact. And check the sample module's proguard-rules.pro against your own release build, because the installation section documents Gradle and AAR installation in detail and says nothing about shrinking, which is where a library built on reflection usually breaks.

Frequently asked questions

Official sources

1. AnyChart/AnyChart-Android on GitHub
2. Issues
3. README