How do their APIs compare?

These two projects operate at very different layers, so their "APIs" aren't really comparable in kind — one is a UI widget library, the other is a hot-patching/build infrastructure system. Let me lay out what each actually exposes.

chrisbanes/android-pulltorefresh — UI widget API

This library's public surface is a set of drop-in View subclasses that mirror standard Android widgets but add pull-to-refresh behavior:

• Widget classes: PullToRefreshListView, PullToRefreshGridView [library/src/com/handmark/pulltorefresh/library/PullToRefreshGridView.java:L1-L27], PullToRefreshWebView, PullToRefreshExpandableListView, PullToRefreshScrollView, etc. — each wraps a native Android widget.
• Base class contract: PullToRefreshBase defines the shared API surface, including nested types like Mode, State, and listener interfaces OnRefreshListener and OnLastItemVisibleListener, as seen used in the sample activity [sample/src/com/handmark/pulltorefresh/samples/PullToRefreshListActivity.java:L33-L37].
• Internal helper interfaces: EmptyViewMethodAccessor lets PullToRefreshBase hijack AdapterView.setEmptyView() calls internally [library/src/com/handmark/pulltorefresh/library/internal/EmptyViewMethodAccessor.java:L17-L24], and ViewCompat provides version-gated view helpers [library/src/com/handmark/pulltorefresh/library/internal/ViewCompat.java:L16-L23].
• Consumption model: Developers declare the widget in XML/layout, then call listener-registration methods (setOnRefreshListener, etc.) in Java, as shown in the sample apps (e.g. PullToRefreshWebViewActivity [sample/src/com/handmark/pulltorefresh/samples/PullToRefreshWebViewActivity.java:L16-L22]).

It's a synchronous, callback-driven UI API — you configure a view and react to gesture events.

tencent/tinker — hot-patch/runtime API

Tinker's public API is service- and application-lifecycle-oriented, not view-oriented:

• Runtime status/helper API: TinkerApplicationHelper exposes static methods for checking/using Tinker's install and patch state from your Application, intended for apps that install Tinker conditionally or per-process [tinker-android/tinker-android-lib-no-op/src/main/java/com/tencent/tinker/lib/tinker/TinkerApplicationHelper.java:L16-L27].
• Low-level dex/zip manipulation APIs: under third-party/aosp-dexutils, classes like DexFormat (dex file format constants such as VERSION_CURRENT, MAGIC_PREFIX, MAX_MEMBER_IDX) [third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dex/DexFormat.java:L63-L100], plus data-model classes like TypeList, MethodId, Code, ClassData that represent dex file structures for patch diffing/merging [third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dex/TypeList.java:L1-L21] [third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dex/MethodId.java:L1-L21] [third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dex/Code.java:L1-L21] [third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dex/ClassData.java:L1-L21].
• Zip utility constants: ZipConstants is explicitly documented as public API — a marker interface whose implementing classes' constants are part of the stable contract [third-party/tinker-ziputils/src/main/java/com/tencent/tinker/ziputils/ziputil/ZipConstants.java:L17-L24].

Tinker's API is layered: a high-level app-facing helper (TinkerApplicationHelper) sits on top of much lower-level binary format manipulation code (dex/zip internals) that most consumers never touch directly.