AlbumCameraRecorder versions its releases by year and builds them on JitPack

The repository is one name and the README calls it another

The repository is AlbumCameraRecorder. The document you are reading heads itself AlbumCameraRecorderX.

So the project renamed its product and kept the coordinates, the repository and the JitPack group. Every dependency line still reads `com.github.zhongjhATC.AlbumCameraRecorder`, so the artifact you depend on is the un-Xed name while the documentation describes the X one.

The default branch is `kotlin`, not `main`, which is a second naming signal. The project is Kotlin, the branch says so, and the legacy line lives on a branch called `androidx` that the README describes as no longer maintained unless there are serious bugs. That legacy branch is where the 1.x versions live, for anyone who wants the more stable option.

The README also links a Chinese version of itself, and the repository root carries three separate readme files: `README.md`, `README_CN.md` and `README_EN.md`.

Which one you land on matters for how much of the document is translated, because the feature list that follows is in English under a heading written in Chinese.

Versions are years and the builds happen on JitPack

The release tags are numbers that look like years, and the newest three are 2029, 2028 and 2027, dated 2026-08-20, 2026-07-31 and 2026-07-23.

The same numbers are the version coordinates, which is why every dependency line ends in the same suffix:

     implementation 'com.github.zhongjhATC.AlbumCameraRecorder:combined:2029'

So the scheme is year-like rather than semantic, and a consumer pinning a dependency is pinning a tag that happens to look like a calendar year.

The distribution route matters more than the scheme. The install instructions say to add JitPack to the repositories block:

     		maven { url 'https://www.jitpack.io' }

Nothing is published to Maven Central. Your build fetches a git tag from this repository and asks JitPack to compile it. That means the availability and the contents of a given version are the responsibility of a third-party build service rather than of a repository you can inspect offline, which is the main reproducibility cost of depending on this library.

There is also a `testmaven/` directory at the root, so at least part of that arrangement is tested inside the project.

Six modules, and the project tells you when you can skip one

The library is not one artifact. It is six modules sharing a group, and the README annotates each one with when you need it.

`combined` exists to simplify the code when you want the core library, the grid and the common module together. `common` is the fallback if you are not using the combined artifact. `multilibrary` is the core, described as covering album, screen recording and audio recording. `grid` is a supplement for displaying content once you have the data and showing upload progress, and the README says plainly that if you only need to obtain photos, videos and audios you do not need it.

`imageedit` covers image editing. `videoedit` covers video editing and is the one with a stated price.

Two features from the list are worth noting for anyone assembling this. You can customise the image reading and processing entirely, with Glide and Fresco named as the libraries you would plug in, which means the consumer supplies the loader rather than the library bundling one. And recording supports segmented recording, while video editing is described as something that will be added in the future.

So the module count is six, and the honest minimum for a capture-only app is two.

videoedit costs 25MB because it bundles ffmpeg

One dependency line carries a size warning in the comment beside it, and it is the most useful thing in the install section.

The video editing module is used for video editing, currently has only the compression function, with more functions promised later, and because it uses ffmpeg it takes up 25M of file size. The advice is to choose it according to the actual situation.

Twenty-five megabytes is not a rounding error in an Android application, and it is paid by every user of the app whether or not they open the editor. That is the shape of the trade the comment is inviting you to make: a smaller dependency graph against a larger download.

The same ffmpeg dependency is what powers the video compression option in the capture flow, where the README describes deep compression as selectable, with image compression either customisable or using LuBan compression in the demo.

So a project that wants compressed video from the recorder and a project that wants a video editor are not the same dependency decision, even though both end up naming the same module. Worth checking whether the compression path can be reached without pulling the editor.

Adding it means turning Jetifier on in your build

The third installation step is two gradle properties, and one of them is a project-wide switch.

    android.enableJetifier=true
    android.useAndroidX=true

Jetifier is what rewrites legacy support-library dependencies to AndroidX, and enabling it in a consuming project applies that rewrite across the whole dependency graph, not just to this library. So a decision about one camera library changes how every other dependency in your app is processed.

The fourth step configures the app module. Source and target compatibility are set to Java 8, core library desugaring is enabled, and two comments explain why: desugaring makes the `java.time` APIs available from API level 26, and `minifyEnabled` is called the key switch for the size reduction that desugaring allows. The comment also notes desugaring is not required if your minimum SDK is already 26.

Together those steps are the real adoption cost of this library. Not six coordinates, but four configuration changes, two of which are project-wide and one of which rewrites your dependency tree.

The compatibility claim appears three different ways

The minimum Android version is stated three times and the three statements do not agree.

The badge at the top links to the Android 5.0 release notes, which is the conventional way to say the library targets from API 21. The feature list says compatibility handling exists for both a low version of 4.1 and the latest Android 16. And the source and target compatibility in the gradle snippet is Java 8.

5.0, 4.1 and a Java 8 language level are three different constraints, and which one governs your build depends on which line of the document you read.

Alongside that there is a self-reported compatibility result. The README states that the library passed a compatibility test at 100 percent and links a report held in the repository, in a file called `WeTest.md`. A compatibility matrix checked into the repository is more useful than a claim without one, and it is the thing to read before assuming a device is covered.

The feature list also claims performance work and careful handling of memory leaks, and describes a complete cache management system. Those are assertions rather than measurements, and no figures accompany them.

Three readmes, a Chinese-named upgrade guide, one mixed-language heading

The documentation surface is wider than the README, and it is not tidy.

Three readme files sit at the root: `README.md`, `README_CN.md` and `README_EN.md`. Alongside them are `LOGIC.md`, `TestStep.md` and `WeTest.md`, plus one file whose name is in Chinese and describes the code changes needed to move from an older version to the latest. A repository whose primary readme is in English carrying an upgrade guide named in Chinese is a small signal about who maintains it and for whom.

The feature list itself is a case in point. Its heading is written in Chinese while all of its entries are in English, and the usage snippet further down interleaves Chinese comments with English code, annotating a camera setting, a mime type set, an album setting with a countable flag, a filter, and an original-image toggle with a maximum original size.

That code is also the only place the settings API is shown at all. There is no configuration reference in the README beyond the module coordinates and the two gradle properties, so anyone who wants to change a capture parameter has to read the demo.

The feature list also points at an external architecture write-up for the camera fragment, hosted on a Chinese developer blog rather than in the repository.

Editorial conclusion

AlbumCameraRecorder fits an Android team that wants a full camera, album and recorder UI in one dependency and is willing to accept a library that dictates its build configuration. It is a poor fit if Jetifier is unacceptable in your project, if you cannot fetch from JitPack at build time, or if you only need one narrow capability and want to avoid a multi-module install. Before you adopt it, settle three things. Work out which of the six modules you actually need, since two of them are optional by the project's own account and the video module alone costs 25MB. Decide whether the current year-numbered line or the unmaintained 1.x branch is right for you, because only serious bugs are being fixed on the old one. And read the gradle requirements, because Jetifier and core library desugaring are not optional flags here. The last push was on 2026-09-24 and the newest release is numbered 2029.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes