How do their APIs compare?

These two projects operate at completely different levels of abstraction, so their "APIs" aren't directly comparable in a meaningful way, but here's how they contrast:

blankj/androidutilcode — broad utility API surface

This is a general-purpose Android utility library organized as a large collection of static-method classes ("Utils" classes), one per concern. From what's retrievable:

• Naming convention: Every utility is a final class of static methods, typically named XxxUtils (e.g. BatteryUtils, AppUtils, CountryUtils, CrashUtils, ProcessUtils, LogUtils), living under com.blankj.utilcode.util (core utilcode module) or com.blankj.subutil.util (rarer, secondary subutil module) — see the imports in [lib/base/src/main/java/com/blankj/base/BaseApplication.java:L1-L24] and the subutil package declarations in [lib/subutil/src/main/java/com/blankj/subutil/util/BatteryUtils.java:L30-L38] and [lib/subutil/src/main/java/com/blankj/subutil/util/CountryUtils.java:L19-L25].
• API shape per utility: mostly stateless static query/action methods, e.g. BatteryUtils.isIgnoringBatteryOptimizations() [lib/subutil/src/main/java/com/blankj/subutil/util/BatteryUtils.java:L46-L61], plus listener-registration patterns for system events, e.g. registerBatteryStatusChangedListener / unregisterBatteryStatusChangedListener backed by a singleton BroadcastReceiver (BatteryChangedReceiver via a lazy holder) [lib/subutil/src/main/java/com/blankj/subutil/util/BatteryUtils.java:L70-L109, L156-L163].
• Supporting types: nested data/result classes like BatteryUtils.Status with getters/setters [lib/subutil/src/main/java/com/blankj/subutil/util/BatteryUtils.java:L164-L189], and @IntDef-based constants for type-safe enums (BatteryStatus) [lib/subutil/src/main/java/com/blankj/subutil/util/BatteryUtils.java:L32-L38].
• The library also ships app-framework scaffolding (base Activity/Presenter/adapter classes such as BasePresenter, BaseItemAdapter, CommonActivity with showLoading()/dismissLoading()) [lib/common/src/main/java/com/blankj/common/activity/CommonActivity.java:L213-L231], but these are demo/framework support rather than the core utility API.

So its "API" is essentially dozens of independent, narrowly-scoped static utility classes you call directly — no central object, no inheritance required, easy to cherry-pick individual utilities.

hugeterry/coordinatortablayout — single custom View API

This repo exposes a much smaller, single-purpose API surface: it's one custom ViewGroup (CoordinatorTabLayout) meant to be dropped into an XML layout, as shown in the usage snippet wrapping a ViewPager with app:layout_behavior="@string/appbar_scrolling_view_behavior" [README.md:L25-L40]. Its API is consumed declaratively through XML attributes/child views rather than through a large set of static helper calls. There's also a small internal helper, SystemView.getStatusBarHeight(Context), used for status-bar-height calculations [coordinatortablayout/src/main/java/cn/hugeterry/coordinatortablayout/utils/SystemView.java:L9-L18].

I wasn't able to retrieve the full CoordinatorTabLayout class body (its setAdapter/listener methods) from the current search results — I only have the XML usage contract and the SystemView helper. If you want, I can dig further into the CoordinatorTabLayout source itself to compare its public method signatures more precisely.

Summary comparison