AlbumCameraRecorderX: A Modular Kotlin Library for Album, Camera, and Audio Capture on Android

What Problem It Solves and Who It Is For

Android developers often need to offer photo capture, video recording, audio recording, and album selection in one screen, like a social media app. Doing this from scratch means writing camera previews, handling runtime permissions, managing file storage, and building a grid UI. AlbumCameraRecorderX bundles these functions into a configurable library. The README describes it as an efficient multimedia support operation library that allows simple configuration of taking photos, accessing albums, recording videos, and recording audio. It also includes a nine-grid function for displaying pictures, videos, and audios. This is for Android developers who want a ready-made multimedia picker and recorder, especially those who want to customize the UI and behavior through APIs rather than building it themselves.

How It Works: Architecture and Data Flow

The library is split into several modules, which the README lists as common, multilibrary, grid, imageedit, and videoedit. The combined module pulls all of them together. The multilibrary module is the core for calling and displaying album, screen recording, and audio recording. The grid module is a supplement for showing the data you obtain, including upload progress. The imageedit module handles image editing, and videoedit handles video compression via ffmpeg. The README points to a separate article for the CameraFragment architecture, indicating that the camera is built on CameraX. The design separates concerns: you can import only the modules you need, which reduces APK size. The data flow starts with a configuration object like CameraSetting or AlbumSetting, then you launch the multimedia activity or fragment, and the library returns the selected or captured files. The grid module then displays them with progress indicators.

Getting It Running: Integration Steps

Integration follows a standard JitPack flow. First, add the JitPack repository to your build file: maven { url 'https://www.jitpack.io' }. Then add dependencies with the version tag, for example implementation 'com.github.zhongjhATC.AlbumCameraRecorder:combined:2029'. You can choose individual modules instead of the combined one. The README also requires enabling Jetifier and AndroidX in your gradle.properties: android.enableJetifier=true and android.useAndroidX=true. In the app module, you must set compileOptions to Java 1.8 and enable coreLibraryDesugaring with coreLibraryDesugaringEnabled true, which allows java.time APIs on older API levels. The usage example shows creating a CameraSetting object, calling mimeTypeSet(MimeType.ofAll()) to allow images and videos, and an AlbumSetting object with options like countable(true) for showing selection numbers and originalEnable(true) for allowing original images. The README recommends downloading the Demo for more functions, as the truncated usage section stops at the audio recorder setup.

The Versioning and Maintenance Trap

The most important caveat is in the README's opening note: This version has just been released. If you want a more stable version, you can choose the androidx branch with version number 1.-.--X. But then it says that androidx branch will no longer be maintained unless there are serious bugs. This is a strange position. The new kotlin branch uses CameraX and has nicer animations, but it is explicitly new. The old branch is stable but abandoned. For a production app, this is a risk. You are either on a new version with unknown bugs or on a dead branch. The release tags are named 2027, 2028, and 2029, which look like date-based versions, not semantic versioning. That makes it hard to judge compatibility or upgrade paths. The author does invite suggestions via Issues, which is positive, but the maintenance status is a genuine failure mode for adopters.

What It Does Not Do Well: Missing Features and Size Costs

The README lists several limitations within the project's own scope. Video editing currently only has compression, and the author says more functions will be added later, but that is a promise, not a fact. The videoedit module uses ffmpeg and takes up 25 MB of file size, which is a significant cost for an APK. The README also mentions that image editing supports color graffiti, text input, mosaic, rotation, and cropping, but it does not specify the output formats or whether editing is reversible. The library supports deep compression for recording and photography, but the README does not detail the compression algorithms or quality settings. Another gap is motion photos: the README says the library adds a motion photo feature and supports viewing them in the system gallery, but it does not explain how to create them or which devices support it. For a library that claims strong compatibility with Android 4.1 through Android 16, the lack of specific device test details beyond a 100% pass claim on a self-reported compatibility report is thin evidence.

A Real Alternative: Matisse and Custom CameraX

A common alternative is Zhihu's Matisse, an open source Android image and video picker. Matisse focuses only on album selection, not recording or audio. It does not include camera capture, video recording, or audio recording. The difference in approach is that Matisse is a picker only, so you would need to combine it with a separate camera library like CameraX directly. That means more integration work but also more control and a smaller dependency footprint if you only need album selection. AlbumCameraRecorderX bundles everything, which is convenient, but it forces you to accept its camera and recording UI unless you customize it heavily. The README mentions that you can customize all image reading and processing, such as using Glide or Fresco, but the core camera flow is still the library's own. If you want to build a custom camera experience from scratch, you would not use this library at all.

Customization and Permissions: The Selling Points

The README emphasizes high customizability. You can customize permission requests, either by letting the library handle them or by providing your own. The built-in permission system includes detection, explaining why a permission is needed, and prompting to jump to settings after repeated denials. You can customize the UI with SVG images, which helps with animation details. The library supports two-finger zoom and single-finger brightness adjustment during recording. It also supports flash and front/back camera switching. The watermark feature supports dynamic watermarks, which is unusual. These features are concrete and useful for apps that need a polished multimedia experience. The modular design means you can avoid the videoedit module if you do not need compression, saving the 25 MB. The MIT license is permissive, so you can use it in commercial projects without copyleft obligations, but you should still review the license text for any attribution requirements.

Cache Management and Performance: What the README Claims

The README lists a complete cache management system and performance optimization with careful handling of memory leaks. It also mentions rich callback interfaces and debugging information. These claims are not backed by benchmarks or code examples in the material. The compatibility test report link is to a WeTest.md file, but the README only says 100% passed, without specifying which devices or test cases. As a reviewer, I cannot verify these claims. The library's use of CameraX is a positive sign because CameraX is Google's recommended API, but the architecture article is in Chinese and not included here. If you adopt this library, you should test memory usage on low-end devices, especially with the nine-grid display and video compression. The README does not specify how cache is managed, such as whether it uses LRU or disk limits, so you may need to read the source code to understand the behavior.

Editorial conclusion

Adopt AlbumCameraRecorderX if you need a single library that covers photo capture, video recording, audio recording, album selection, and a nine-grid display, and you are comfortable with a version that the author explicitly labels as newly released. Do not adopt it if you require a stable, long-term maintained codebase, because the androidx branch is no longer maintained and this kotlin branch is described as just released. Before committing, verify the current release tag (2029) works with your target Android versions, test the videoedit module's 25 MB ffmpeg size against your APK budget, and check the JitPack repository availability for your build environment. The library's MIT license and modular imports reduce risk, but the maintenance status and the author's own caution about stability should be your first checks.

Official sources

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