android-utils, an Android toolbox of forty-odd Java classes

A utility library whose package repository disappeared

The project is described as a collection of most of the utility classes used in Android application development, and the readme is explicit that some of them were gathered from elsewhere on the web while others were written by the developer. The stated purpose is to raise development efficiency and reduce the reinvention of wheels.

The three advertised characteristics are comprehensiveness, with dozens of classes covering files, network, images, device information and encryption, lightness, with no excessive third-party dependencies and plug-and-play use, and compatibility, with a minimum of API 15.

What is remarkable is the state of the distribution. The readme carries a note that because the Bintray and JCenter services have shut down, the original Maven repository import method no longer works, and it recommends using JitPack instead or importing the util module directly as a local library in your project. The licence file dates from 2014 to 2017, the CI configuration is a Travis file, and the repository publishes no tagged releases.

That combination is the honest state of a library that outlived its distribution channel. The code is still there, and the paths to use it are documented, but the version of the artefact you get is whatever commit you clone. There is no upgrade path, because there is no release to upgrade from.

Copying the module is the recommended path

The first integration route is to vendor the module, and the readme calls it the recommended one. It is four steps.

Clone the repository, copy the util folder into your own project, include the module in settings.gradle, and add the dependency in your app module's build.gradle:

include ':util'

dependencies {
    implementation project(':util')
}

The steps are simple because the module is a plain Android library with no publication metadata. Once the folder is in your tree, the Gradle build treats it like any other module in a multi-module project, and the source layout is the conventional one, with the classes under util/src/main/java/com/ihongqiqu/util/ and the same package prefix used for the Application and crash-handler classes in com.ihongqiqu.app.

Vendoring has an obvious cost that the readme does not spell out. The library is now your code. There is no upstream release to pull in, so a fix to a class in the library is a manual merge, and the copy in your tree will diverge from the original as your application adds its own changes to it. That is fine for a handful of static helper methods and awkward for anything that gets maintained over years.

The alternative to copying is to depend on the module as a Gradle project from a fork, which is the second route.

JitPack works, but it works through your fork

The second route is JitPack, and it has one condition that changes its character. The readme says that if you have already forked this project and pushed it to GitHub, you can bring it in through JitPack.

The repository configuration is the standard one:

allprojects {
    repositories {
        // ...
        maven { url 'https://jitpack.io' }
    }
}

And the dependency coordinate has a shape worth reading carefully:

dependencies {
    implementation 'com.github.您的用户名:android-utils:Tag版本号'
}

The group is com.github followed by your own user name, the artefact is the repository name, and the version is a tag. Which means the dependency you install is a build of your fork, and the version you ask for is a tag in your fork.

That is a real constraint rather than a technicality. JitPack is a service that builds a Git repository on demand and serves it as a Maven artefact, and it can build any fork. So a team can fork the project, tag a commit, and consume it without copying files. But the team now owns a fork, and the fork has to be kept in step with the upstream, and if the upstream is dead, as the release history suggests, the fork is simply the project's home.

It is a better arrangement than copying for a project that intends to maintain the library, and a worse one for a project that intends to consume it and move on.

The class list, from animations to a reflection helper for resource ids

The readme's catalogue runs from A to Z and covers roughly forty-five classes, and reading it is the fastest way to understand what a project gets.

The familiar ground is covered: AnimationUtils and ViewAnimationUtils for animations, BitmapUtil for bitmap handling, CommonUtil and StringUtils for general helpers, DateUtils for date formatting and parsing, FileUtils for reading, writing, copying and deleting, and ResourceUtils for reading assets and raw resources. DisplayUtils does the dp and px conversion, Colors holds common colour values, and JSONUtils handles JSON parsing and wrapping.

Then there are the Android-specific ones that are less often written from scratch. DataCleanManager clears application data across the internal and external cache, the database, SharedPreferences, files and custom directories. DatabaseExportUtils exports an application database. DownloadManagerPro wraps the system download manager, and PollingUtils starts and stops a polling service. LocationUtils converts between coordinates and addresses, and NetUtil detects network state and type. DeviceStatusUtils reads the phone status, covering network, Bluetooth, screen brightness, airplane mode and volume, while DeviceUtils gets a unique device identifier and ImsiUtil gets the IMSI.

A few entries are unusual enough to be memorable. RUtils fetches resource ids by reflection, which is a trick for reading a resource id whose name is only known at runtime. HanziToPinyin converts Chinese characters to pinyin. DoubleKeyValueMap is a two-key data structure. ViewFinder is an alternative to findViewById. ShellUtils executes shell commands and supports root, and PackageUtils covers application installation and download, including silent installation.

The application-level classes are the last group: BaseApplication with a built-in global exception handler, BaseCrashHandler that captures exceptions, saves them to a file and can upload them on the next launch, RebootThreadExceptionHandler that restarts the app on an unknown exception, and StartAppReceiver, a broadcast receiver that starts the application.

Permissions, crash capture and the one-line log switch

The configuration section is where a library of this kind earns its keep, because it is where the cost of using it becomes concrete.

The readme asks you to add the permissions you need to your AndroidManifest as required, and lists them: INTERNET, WRITE_EXTERNAL_STORAGE, ACCESS_NETWORK_STATE, BLUETOOTH_ADMIN, BLUETOOTH, and READ_PHONE_STATE with a comment that it is used to obtain the UUID for device status. That is a wide list, and it is the list the classes need rather than the list your application needs, since the library cannot know which of its classes you use. The permission list is the first thing to read before copying the module in, because the classes that need READ_PHONE_STATE, external storage and Bluetooth are the ones most applications will delete and the ones a privacy review will ask about.

The global crash capture is optional and is configured by pointing the application element at the bundled Application class:

<application
    android:name="com.ihongqiqu.app.BaseApplication" 
    ...>
</application>

And the log output is controlled by a single static field, which the readme suggests setting when you publish a formal version:

LogUtils.DEBUG_LEVEL = Log.ASSERT;

That is a blunt but effective mechanism, and it is worth understanding what it does and does not do. It changes the threshold below which LogUtils suppresses output, which removes the library's own verbose logging from a release build. It does not remove the string constants, and it does not stop a call site in your own code from logging.

The crash handler and the restart handler are the two entries with real behavioural consequences, since the second one restarts the application when an unknown exception occurs, and a restart loop caused by a persistent error is a failure mode you inherit along with the convenience.

Proguard rules and the advice to read the framework first

The last configuration item is the Proguard rules, and the readme is clear that they are part of using the library rather than an optional extra. If your project obfuscates its code, you are told to add the following to your rules file, whether it is named proguard-rules.pro or proguard.cfg:

-keep class com.ihongqiqu.** { *; }
-keepclassmembers class com.ihongqiqu.** { *; }
-dontwarn com.ihongqiqu.**

The reason is the reflection class. RUtils resolves resource ids by reflection, and obfuscation renames fields and classes, so a library that reaches into the generated R class by name needs the names kept. The keep rules are broad, covering everything in the package, which is the safe choice and also means the whole library survives the shrinker.

The readme closes with a piece of advice that is worth more than any of the classes. Before reinventing a wheel, look at the utility classes that ship with the Android framework itself, and the readme lists some of them: DatabaseUtils, TransitionUtils, AnimationUtils, ViewAnimationUtils, URLUtil, BluetoothLeUtils, GestureUtils, TextUtils, the framework's own DateUtils, FileUtils, NetworkUtils, MathUtils, TimeUtils, ExceptionUtils and PhoneNumberUtils.

That list is a useful corrective for the whole project. A large part of what this library offers overlaps with what the platform already provides, and the version of the platform in your minSdk decides whether the framework version is available. A library that covers forty classes is partly a snapshot of what the framework did not have yet.

Where this library is the wrong choice

The first limit is the one the readme states plainly: there is no package to depend on. JCenter and Bintray are gone, the repository publishes no releases, and the two documented routes are copying the code into your tree or maintaining a fork. A team that wants a managed dependency, with a version constraint in a lock file and an upgrade path, cannot get it here, and that is a structural problem rather than a configuration mistake.

The second is the age of the code and of the platform assumptions behind it. The licence dates from 2014 to 2017, and several of the classes are built on APIs the platform has since restricted. WRITE_EXTERNAL_STORAGE is meaningless under scoped storage, BLUETOOTH_ADMIN was deprecated in favour of the Bluetooth permissions, silent installation requires privileges a normal application does not have, and reading a device identifier or an IMSI is subject to runtime permissions and to the distribution policies of the app stores. A class that is technically present and practically unusable is worse than one that is absent, because it looks like a solution.

The third is the permission surface. A library that declares INTERNET, external storage, Bluetooth and phone state is a library that will be questioned in a privacy review, and the fix is to delete the classes you do not want rather than to declare fewer permissions, since a permission you declare and never use is a finding in itself.

The fourth is the two classes that should never ship. ShellUtils executes shell commands and supports root, and PackageUtils covers silent installation. Both are legitimate for a device-management or research application and neither belongs in an application that a user installs from a store.

The fifth is the maintenance picture. The repository has no releases, a Travis configuration from an earlier era, and a last push on 2026-09-17 that may be a housekeeping change rather than a maintained code base. You are not adopting a maintained dependency, you are adopting a snapshot and deciding what to do with it, and the honest approach is to copy the handful of classes you actually want and own them from the first day.

Editorial conclusion

The library fits an Android team that wants a file, network, device and crypto helper library in one place, that is comfortable vendoring a Java module into its own tree, and that is willing to strip the classes it does not want. It does not fit a project that wants a managed dependency from a registry, since the original Maven distribution is gone and the JitPack route requires forking the project, and it does not fit a modern release that cares about scoped storage, runtime permissions or Play policy, because several of the classes rely on APIs the platform has since restricted. Before copying it in, read the permission list and decide which of those classes you actually want, since the library asks for Bluetooth, phone state and external storage permissions, check the Proguard rules into your own configuration, and treat the silent install and root shell classes as something to delete rather than to ship. The licence is Apache-2.0, the last push was on 2026-09-17, and there are no tagged releases.

Frequently asked questions

Official sources

1. Issues
2. jingle1267/android-utils on GitHub
3. License: Apache-2.0
4. Project website
5. README