AppUpdater splits the download from the dialog on purpose

Two modules, deliberately independent

The core library is split into app-updater and app-dialog, and the reason is stated as a design decision rather than an accident. The download and the dialog are two different functions, and they are completely independent, so you can decouple them and reduce intrusion into your app. If you only need the pure download and update functionality, depending on app-updater alone is enough. If you want user interaction with a dialog while the download runs, the combination of app-updater and app-dialog is the pairing. And app-dialog on its own applies to any scenario that needs a dialog. The project describes the result as a one click, configuration free integration that gives you a reliable update experience, and the feature list is correspondingly concrete: focus on one click updates, a small size, support for listening to the download and for a custom download flow, retry when a download fails, MD5 verification of the file so the same file is not downloaded twice, a notification whose content and flow are fully configurable, the ability to cancel a download, and the choice of HttpsURLConnection or OkHttpClient for the transfer itself.

What the download side actually does

The app-updater module is described as a lightweight app update library that wraps the whole download and update flow and provides an out of the box one click update, so you do not have to think about the technical details, while still allowing custom configuration. The configuration object is a builder, and the documented options map to the feature list. The URL is the only required field, everything else has a default, and the defaults are the recommended configuration according to the documentation. There is a filename for the saved APK, a switch for whether the notification bar is shown at all, a switch for whether the download percentage is displayed in that notification, a switch for whether the installer is requested automatically once the download finishes, a pluggable HTTP manager, and a pluggable notification handler. A download listener reports the lifecycle through five callbacks, on start with the URL, on progress with bytes downloaded and total, on success with the finished file, on error with the cause, and on cancel. The one line form of the whole thing is a constructor taking a context and the APK URL followed by a call to start.

app-dialog is a general dialog library

The app-dialog module is a general purpose Dialog and DialogFragment component library that supports any style and interaction, and it exists to make prompt dialogs quick to build. The documented example shows a configuration object built with a chain of setters for the title, the content, the confirm label, the cancel label, and the click listeners for each, after which the dialog is shown. The library also handles a custom layout, where a second constructor takes a layout resource and the cancel and confirm button ids, and it exposes a view holder from the configuration object so that any view inside that custom layout can be manipulated directly, with setters for text on a given view id. The recommendation in the documentation is to reach for that view holder when the custom dialog is complex, because chaining setters only covers the standard fields. In other words, app-dialog is not a themed update prompt but a small dialog toolkit that the update flow happens to use.

2.x is a Kotlin rewrite with a DSL

There is a version note that matters if you are upgrading. In 2.x the codebase was rewritten in Kotlin during a refactor, and while the traditional chained calls are retained, support for the Kotlin DSL style was added, which significantly improves the experience in a Kotlin environment. The new version stays compatible with Java calls while adjusting some interface definitions and configuration fields. The overall architecture follows the design ideas of 1.x, and the documentation is explicit that some breaking changes exist between the two, so a team moving from 1.x should read the usage notes rather than assume the API is unchanged. If you do not want to upgrade, the 1.x branch is still there and still documented. The DSL form mirrors the chain, with the same fields assigned as properties inside a configuration block, and the custom layout case works the same way, so the difference is syntax rather than capability.

Installing from a remote repository

The library is on Maven Central and also on JitPack, and the Gradle setup is two steps. First you add the remote repository to the project level build.gradle or settings.gradle file:

repositories {
    //...
    mavenCentral()
}

Then you add the dependency in the module level build.gradle file, and you take the modules you actually need:

//app-updater
implementation 'com.github.jenly1314.AppUpdater:app-updater:2.2.0'
//app-dialog
implementation 'com.github.jenly1314.AppUpdater:app-dialog:2.2.0'

The coordinate carries the group id com.github.jenly1314.AppUpdater with the module as the artifact, and the version is the release you want. The two modules are versioned together, which is convenient, since the pair that most apps want is the pair that ships in the same release.

Version, platform floor and the demo app

The badges at the top of the README give the operational facts. The minimum API level is 21, so the library is not restricted to recent Android versions. The current release is 2.2.0 published on 2026-08-04, after 2.1.0 on 2025-12-09 and 2.0.1 on 2025-08-31, and the last push to the repository was on 2026-08-04, the same day as the newest release, so the project is being maintained on a normal cadence rather than abandoned. There is a CI workflow for the build, a changelog, and a demo APK published in the repository so you can install the sample application and see the notification and the dialog behaviour without writing any code. The documentation site is published through the GitHub Pages site for the project, and the repository carries a mkdocs configuration and a build_docs.sh script for building it. The licence is MIT.

The repository layout

The tree is the layout of a Gradle multi module Android project. There is an app-updater/ directory and an app-dialog/ directory for the two published modules, an app/ directory that holds the sample application and its release APK, and a test.md file at the root. The build is defined by build.gradle.kts, settings.gradle.kts and gradle.properties, with the Gradle wrapper checked in as gradlew and gradlew.bat, and a gradle/ directory. The documentation tooling is mkdocs.yml with build_docs.sh, and there is a jitpack.yml for the JitPack build. There are also older CI configurations, a.travis.yml and a.circleci/ directory, alongside the GitHub Actions build workflow. There is also a.pre-commit or editor configuration in.editorconfig, a CHANGELOG.md and a LICENSE. The point of the layout is that the two libraries are built independently of the sample app, so a consumer pulls one artefact or two and never the demo.

Editorial conclusion

AppUpdater fits an Android team that ships APKs outside the Play Store, whether to its own users or to enterprise customers, and that wants the update prompt and the download progress handled by something other than hand written code. It does not fit a team that ships through the Play Store, since the store handles updates and the library is built around downloading an APK directly. It does not fit a project that needs the update to be verifiable against a signature scheme the library does not implement, and it does not fit a team that cannot accept the 1.x to 2.x breaking changes. Before you adopt it, read the version notes, because 2.0 was a Kotlin rewrite with a new DSL, and check that the minimum API level of your app is at least 21.

Frequently asked questions

Official sources

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