ImagePicker: A WeChat-style Android picker that stopped evolving in 2017

What ImagePicker solves and who it targets

ImagePicker is an Android library that reproduces the visual and interaction pattern of WeChat's photo album picker. It handles the tedious parts of selecting images from the device, taking a photo directly, cropping a single selection into a rectangle or circle, and rotating the result. The intended user is an Android developer who wants a drop-in gallery screen without building the grid, the folder list, and the crop view from scratch. The README positions it as a complete custom album, and the demo project is the primary documentation. The library is written in Java and targets the classic support-library era, which matters if your app has already moved to AndroidX.

The actual mechanism: a singleton config, an activity, and a callback

The design follows a simple flow. You configure a global ImagePicker instance once, typically in Application.onCreate. That instance holds the image loader, the crop style, the selection limit, and flags like showCamera. Then you start ImageGridActivity with an Intent, either to browse the album or, by adding EXTRAS_TAKE_PICKERS, to open the camera directly. The selected images come back through onActivityResult as an ArrayList<ImageItem> in the Intent extra ImagePicker.EXTRA_RESULT_ITEMS. The result code is ImagePicker.RESULT_CODE_ITEMS. This is a classic startActivityForResult pattern, not a modern Activity Result API. The library's internal change log shows it replaced GridView with RecyclerView in version 0.5.1 to avoid full-list refreshes when the selection state changes, but the external API stayed the same.

Getting it running: the exact dependency and configuration keys

For Android Studio, the README gives one line: compile 'com.lzy.widget:imagepicker:0.6.1'. The version in the repository's release list stops at 0.5.1, but the README references 0.6.1, so verify which artifact is actually published. After adding the dependency, you implement the ImageLoader interface. The README shows a Picasso-based loader that calls displayImage with an Activity, a file path, an ImageView, and width and height. You then configure the picker through setters: setImageLoader, setShowCamera, setCrop, setSaveRectangle, setSelectLimit, setStyle, and setFocusWidth. The crop style is CropImageView.Style.RECTANGLE or the circular equivalent. Output dimensions come from setFocusWidth and setFocusHeight for the crop frame, and outPutX and outPutY for the saved image size. The README warns that the preview screen has an 'original image' checkbox that is UI-only, with no compression implemented.

The sharp edges: unmaintained, no compression, and provider conflicts

The most obvious limitation is the project's own status. The README states, '由于个人时间有限，该项目停止维护', which means the project has stopped being maintained. The last push was April 2017. That is not a problem if the library works for your use case, but it is a real risk for anything involving newer Android versions. The README also explicitly says the 'original image' checkbox is only UI, so users who tap it will not get an uncompressed image. That is a functional gap, not a cosmetic one. The change log mentions provider conflicts with the host app, and a fix in version 0.5.0, but the FileProvider setup still requires attention. The log also notes that using Picasso can cause images to reload after selection changes, and recommends Glide instead. These are concrete caveats that any adopter should test before shipping.

Where ImagePicker is the wrong tool

If your app needs to handle large image sets with performance tuning, or if you need to apply filters or edit metadata, this library is not the right fit. It is a picker and cropper, not an image processing pipeline. The crop operation is limited to rectangle and circle shapes, with no freeform or aspect-ratio presets beyond what you set manually. The lack of compression logic means you cannot rely on it to reduce file size before upload; you would need a separate step. The library also assumes a traditional Activity result flow, so if you are building with Jetpack Compose or the Activity Result API, you will have to wrap it yourself. The unmaintained status makes it a poor choice for a greenfield project that expects to track Android platform changes.

A real alternative: GalleryFinal, the stated reference

The README credits GalleryFinal as one of the projects ImagePicker was based on. GalleryFinal is a similar Android image selection library, also in Java, with a broader feature set that includes folder management, multiple selection, and cropping. The key difference in approach is that GalleryFinal appears to have a more active history and a different configuration model, though you should verify its current maintenance status before choosing. The README explicitly says '喜欢原作的可以去使用', which translates to 'if you like the original, you can go use it'. That is an honest admission that the original may suit some users better. For a developer who needs a maintained library, GalleryFinal is worth evaluating against ImagePicker's simpler API.

Maintenance and license implications

The project is under Apache-2.0, which allows commercial use, modification, and distribution, provided you keep the license notice. The copyright line in the license block is 'Copyright 2016 jeasonlzy(廖子尧)'. The maintenance situation is clear: the repository is not archived, but the README says maintenance has stopped. The change log shows a series of fixes up to 0.6.1, including memory leaks, Android 7.0 camera crashes, and provider conflicts. Those fixes are valuable, but they stopped in 2017. If you adopt ImagePicker, you take on the cost of forking it for any future bug. The license permits that, but you will need to maintain the fork yourself. There is no indication of a migration path or a successor project.

Editorial conclusion

Adopt ImagePicker if you need a WeChat-like multi-select gallery with built-in rectangular or circular cropping and you can live with a frozen codebase from 2017. Do not adopt it if you require active maintenance, original-image compression, or modern AndroidX compatibility without forking. Before integrating, verify the FileProvider setup against your target SDK, test camera capture on Android 7.0 and above, and check that the unmaintained preview UI's 'original image' checkbox does not mislead your users. The project's own README says it is no longer maintained, so treat any merge request as your only path to fixes.

Frequently asked questions

Official sources

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