How do their APIs compare?

Comparing the two libraries at the API-design level, since they solve very different problems (a general-purpose Android utility collection vs. a networking wrapper around OkHttp):

blankj/androidutilcode

Its API style is a large collection of static utility classes, organized into two modules per the README: utilcode (commonly used utilities) and subutil (rarer, supporting utilities) [README.md excerpt in repository data]. The consumption pattern is calling static helper methods directly (e.g. XxxUtils.doSomething()), grouped by domain (file, string, device, network, etc. — per the module split described in the README). There's no builder/request-chaining pattern here; it's a toolbox of independent static methods you call as needed, with each utility class scoped to one concern.

hongyangandroid/okhttputils

Its API is built around a fluent builder chain on top of OkHttp, centered on the OkHttpUtils entry point:

• Requests are constructed with method-specific builders — OkHttpUtils.get(), .put(), .delete(), .head(), .patch() — followed by chained configuration like .url(...), .addParams(...), .requestBody(...), then finalized with .build() and .execute(callback) [README.md:L139-L164, README.md:L336-L350].
• Callbacks are polymorphic per response type (e.g. StringCallback, or file-download callbacks with onBefore, inProgress, onError, onResponse), shown in the sample activity [sample-okhttp/src/main/java/com/zhy/sample_okhttp/MainActivity.java:L312-L334].
• Client-level configuration is centralized: you build a standard okhttp3.OkHttpClient.Builder (timeouts, interceptors, SSL) and register it once via OkHttpUtils.initClient(okHttpClient) in your Application class [README.md:L36-L61].
• HTTPS/SSL configuration is handled by a dedicated helper class, HttpsUtils, which produces an SSLParams object (socket factory + trust manager) for trust-all, custom-certificate, or mutual-auth (双向认证) scenarios [README.md:L100-L138, okhttputils/src/main/java/com/zhy/http/okhttp/https/HttpsUtils.java:L147-L186].
• Internally, there's a small Platform abstraction (under com.zhy.http.okhttp.utils.Platform) apparently used for platform/threading concerns like getting the main-thread Handler/Executor [okhttputils/src/main/java/com/zhy/http/okhttp/utils/Platform.java:L1-L24].

Key contrasts

Aspect	androidutilcode	okhttputils
API shape	Static utility methods, one class per concern	Fluent builder chain rooted at OkHttpUtils
Scope	Broad, general-purpose Android helpers	Narrow, focused on wrapping OkHttp requests
Configuration	N/A (stateless utils)	Centralized one-time initClient() setup
Async handling	Not applicable in the shown data	Callback interfaces (onResponse/onError/inProgress)
Extensibility	Add new static utility classes	Add new request-type builders / callback types, or supply custom SSLSocketFactory

In short, androidutilcode's API is a flat, stateless toolbox meant for ad-hoc calls anywhere in your code, while okhttputils's API is a stateful, chained request-building DSL wrapping OkHttp, with a distinct callback-based async model and dedicated SSL configuration surface via HttpsUtils.

If you want, I can pull more detail on specific utilcode classes (e.g. file, device, or string utils) to compare method-naming conventions against okhttputils's builder methods.

FOLLOW_UPS:

• What utility categories exist in utilcode module?
• How does okhttputils handle download progress callbacks?
• What SSL/HTTPS options does HttpsUtils support?