RoundCornerProgressBar: rounded Android progress bars for View and Compose

What RoundCornerProgressBar solves, and who it is for

Android's stock ProgressBar is a horizontal bar with square ends. Rounding those ends means either a custom drawable with hand-tuned corner radii or a bespoke View, and neither survives a design review that asks for gradient fills, a secondary progress layer and a colour change at runtime. RoundCornerProgressBar exists to remove that work. The README states the intent plainly: "Round corner is cool. Let's make your progress bar with round corner".

The target reader is an Android developer who already knows what a progress bar is and wants a specific visual result. The library covers both UI toolkits in one repository, which matters if your app is mid-migration from View to Compose: the README says both modules "share the same look, animation and feature set, so you can mix them in the same project". That is the strongest argument for this library over writing your own drawable. A hand-rolled rounded drawable will not match a Compose implementation pixel for pixel, and keeping two of them in sync is the kind of chore that gets deferred until the two screens look different.

It is not a general-purpose UI kit. There is no theming system, no token set, and no integration with Material components beyond the fact that it is an Android View or a Composable. If you want a progress bar that inherits your Material theme automatically, this library asks you to set its colours yourself.

Two artifacts, one feature set: how the modules are split

The repository root contains two module directories, view/ and compose/, alongside an app/ module used for the demo. Each module publishes its own Maven Central artifact: com.akexorcist:roundcornerprogressbar-view for Android View and com.akexorcist:roundcornerprogressbar-compose for Jetpack Compose. Documentation lives inside each module as view/README.md and compose/README.md, and the root README is largely a pointer to those two files.

This split is the architectural decision that shapes everything else. There is no shared runtime dependency between the two artifacts, so a View-only app does not pull in Compose, and a Compose-only app does not pull in the View classes. The cost is that the root README does not document either API. Anyone who reads only the root file learns the artifact coordinates and the feature list, then has to open a second document to find out how to add the component to a layout or a composable. That is a small but real friction point, and it is why the install section below points at the module docs rather than the root.

The feature list itself is shared and consistent across both modules. On the standard side: primary and secondary progress, customisable colours for primary progress, secondary progress and the progress background, configurable background padding, configurable corner radius, reversed progress, gradient colour, and progress change animation. On the component side: CenteredRoundCornerProgressBar, which expands progress from the centre; IconRoundCornerProgressBar, which adds a heading icon; TextRoundCornerProgressBar, which places text inside the progress; and the indeterminate variants IndeterminateRoundCornerProgressBar and IndeterminateCenteredRoundCornerProgressBar.

Adding the dependency and rendering a first bar

Both artifacts are on Maven Central, and the README gives the Gradle coordinates directly. The version shown here is the one the README publishes, 2.3.0, which matches the release tagged 2026-06-14. Add only the module that matches your UI toolkit.

// Android View
implementation("com.akexorcist:roundcornerprogressbar-view:2.3.0")

// Jetpack Compose
implementation("com.akexorcist:roundcornerprogressbar-compose:2.3.0")

The README does not show a layout XML snippet or a composable call in the root file, so the next step is to open view/README.md or compose/README.md depending on which artifact you added. That is where the class names and the attribute or parameter names are documented. Do not guess attribute names from the feature list; the root README lists capabilities such as secondary progress and corner radius as prose, not as XML attributes or Compose parameters.

To see the components running before you wire anything up, the README points at a demo app on Google Play under the package com.akexorcist.roundcornerprogressbar. Installing that is the fastest way to check that the rounded look matches what your designer expects, including the gradient and animation behaviour, without writing a line of code. The minimum supported API level is 17, per the badge in the README.

Where the library stops being the right tool

The name is literal. This is a round corner progress bar, and the shape is a horizontal bar with rounded ends. If you need a circular determinate indicator, the kind that draws an arc around a ring, this library does not provide one. The component variants it does provide are CenteredRoundCornerProgressBar, IconRoundCornerProgressBar, TextRoundCornerProgressBar and the two indeterminate bars, and all of them are horizontal.

The second limitation is documentation depth. The root README describes features in a bullet list and defers the API to two module files. There is a CHANGELOG.md and a MIGRATION.md in the repository, which is more than many small libraries offer, but the root file does not document rollback, deprecation policy or how the Compose and View APIs map onto each other beyond the claim that the feature sets match. If your team needs a documented stability guarantee before adding a dependency, that documentation is not in the root README.

Third, this is a styling component. It renders a value you give it. It does not measure anything, does not estimate remaining time, and does not decide whether a progress value is meaningful. If your actual problem is that a long operation has no reliable completion percentage, a better-looking bar will not fix it; you will be animating a number that does not correspond to reality. That is a product problem, not a rendering problem, and no progress bar library solves it.

RoundCornerProgressBar compared with a custom drawable

The realistic alternative is not another library. It is a custom drawable or a small custom View using a rounded rectangle shape with a clip, which is what most Android teams reach for first. The difference in approach is where the complexity sits. A custom drawable puts the corner radius, padding and colour in XML, and you write the progress logic yourself: two layers for primary and secondary progress, a gradient shader if you want one, and an animator if you want the value to move smoothly. That is entirely doable, and it keeps your dependency count at zero.

RoundCornerProgressBar packages those pieces as named components. You get the secondary progress layer, the gradient option, the animation, the reversed mode, the centre-expanding variant and the indeterminate variants without writing them. The trade-off is that you now depend on a library whose API surface is documented in two module READMEs, and whose visual behaviour you cannot adjust below the level of the options it exposes. If your design calls for something the library does not offer, such as a vertical bar or a segmented bar, you are back to writing it yourself, and now you have a dependency you are not using for that screen.

A second comparison worth naming: if you are on Compose and only need a Material-styled indicator, the Material progress components may already cover you, and adding a third-party artifact for a rounded end is harder to justify. RoundCornerProgressBar earns its place when the rounded look, the secondary progress layer or the centre-expanding behaviour is a requirement rather than a preference.

Maintenance, release cadence and licence

The repository is not archived, and the last push was on 2026-06-14, the same day release 2.3.0 was tagged. Before that, 2.2.2 and 2.2.1 were both tagged on 2025-07-21, and 2.2.1 and 2.2.2 landed about an hour and a half apart, which looks like a quick follow-up fix rather than a planned release. The cadence is therefore occasional: a burst of activity, then a gap. There is a GitHub Actions workflow configured for Android, referenced by the workflow badge in the README, so there is some continuous integration in place.

The upgrade cost is the usual Android dependency cost. The README points at MIGRATION.md for migration guidance, and a CHANGELOG.md exists for release history, so version-to-version changes are at least recorded. Because the two artifacts are versioned together at the same number, a View app and a Compose app in the same repository can move in lockstep, which removes one class of version-skew problem. What the README does not state is a support window or a policy for dropping old API levels; the minimum is API 17 as of this README, and nothing says how long that floor will hold.

The licence is Apache-2.0, with the copyright line reading "Copyright 2026 Akexorcist". Apache-2.0 permits commercial and closed-source use and includes a patent grant, and it requires that you retain the licence and notice files and state significant changes. It also ships an explicit disclaimer of warranty. That is a permissive licence with no copyleft obligation, but the notice-retention requirement is real and is the kind of thing that gets missed when a dependency is added through a build file and never looked at again. This is a description of the licence text, not legal advice; route the specifics through whoever handles your dependency policy.

Editorial conclusion

Adopt it if you need a rounded, colour-customisable progress bar with secondary progress, gradient fill, centre expansion or an indeterminate variant, and you are happy to depend on a small single-author library. Do not adopt it if you need a circular determinate indicator, a measurement or benchmarking widget, or a component whose behaviour is documented beyond the two module READMEs and the demo app. Before you commit, verify the exact artifact name for your UI toolkit, confirm the API 17 minimum against your own minSdk, and read view/README.md or compose/README.md rather than the root README, because the root file only points at them.

Frequently asked questions

Official sources

1. akexorcist/round-corner-progress-bar on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases