How do their APIs compare?

Here's the comparison, based on what's directly evidenced in the retrieved code:

Different API philosophies entirely

blankj/androidutilcode exposes a static-method, utility-class API. Nearly everything is a stateless helper you call directly without instantiating anything:

• CountryUtils.getCountryCodeBySim(defaultValue), CountryUtils.getCountryCodeByLanguage(defaultValue) [lib/subutil/src/main/java/com/blankj/subutil/util/CountryUtils.java:L28-L43]
• AppStoreUtils.getAppStoreIntent(...) overloads for jumping to an app store, with device-specific branching (Samsung, Leeco) handled internally [lib/subutil/src/main/java/com/blankj/subutil/util/AppStoreUtils.java:L23-L136]
• BatteryUtils's inner status class exposes batteryStatus2String(int status) as a static helper [lib/subutil/src/main/java/com/blankj/subutil/util/BatteryUtils.java:L196-L210]

This is a classic "toolbox" API surface: dozens of independent XxxUtils classes, each with static methods, no shared object model, minimal state. You call what you need and get a primitive/Intent/String back.

cymcsg/ultimaterecyclerview exposes an object-oriented, inheritance-based widget API centered on RecyclerView extension. Its API shape is:

• Abstract adapter base classes you subclass and implement callback methods on, e.g. BaseQuickAdapter/EnhancedQuickAdapter, which are explicitly designed so "you only need to provide the convert() implementation" [UltimateRecyclerView/.../BaseQuickAdapter.java:L30-L34, UltimateRecyclerView/.../EnhancedQuickAdapter.java:L23-L32]
• Interface-based callback contracts, like ItemTouchHelperAdapter and ItemTouchHelperViewHolder, which views/adapters implement to receive drag/swipe/dismiss events [UltimateRecyclerView/.../ItemTouchHelperAdapter.java:L17-L26, UltimateRecyclerView/.../ItemTouchHelperViewHolder.java:L17-L26]
• Protected/overridable hook methods like getAdapterAnimations(View, AdapterAnimationType) returning Animator[], and onItemMove(fromPosition, toPosition) that calls notifyItemMoved — both duplicated nearly identically in NormalUltimateViewAdapter and UltimateViewAdapter [UltimateRecyclerView/.../NormalUltimateViewAdapter.java:L232-L259, UltimateRecyclerView/.../UltimateViewAdapter.java:L624-L663]

This is a widget-library API: you extend base classes, override hooks, and the library calls back into your code — the inverse-of-control pattern typical of Android RecyclerView adapters.

Concrete contrasts

Aspect	androidutilcode	ultimaterecyclerview
Primary unit	Static utility methods	Abstract classes / interfaces to extend
State	Mostly stateless helpers	Stateful adapters/ViewHolders with animation, item-move state
Extension model	None — you call methods directly	Subclassing + method overriding (getAdapterAnimations, convert())
Typical return	Primitives, Intent, String	Animator[], view holders, adapter callbacks
Duplication note	Each XxxUtils is self-contained	getAdapterAnimations/onItemMove logic appears duplicated verbatim between NormalUltimateViewAdapter and UltimateViewAdapter [UltimateRecyclerView/.../NormalUltimateViewAdapter.java:L232-L259] vs [UltimateRecyclerView/.../UltimateViewAdapter.java:L624-L663]

Note that the retrieved androidutilcode chunks lean toward subutil (the secondary, less-common-use module) rather than the core utilcode module referenced in the README [README.md excerpt], so a full API comparison of the primary utilcode static classes (e.g. string/file/network utils) would need a more targeted