How do their APIs compare?

These two repositories aren't really comparable at the level of "an API surface" in the same sense — they solve completely different problems and are structured very differently. Here's a concrete breakdown of what "API" means in each:

naman14/timber — an app, not a library

Timber is a standalone Material Design music player Android application. It doesn't expose a public API for other apps/libraries to consume in a packaged sense. What it has instead are internal service/interface boundaries:

• MusicService — the core playback engine (an Android Service), with internal methods like updateCursor, openCurrentAndNext, reloadQueue, openFile [app/src/main/java/com/naman14/timber/MusicService.java:L819-L858, L1379-L1418]. These are private/package-internal, not meant for external consumption.
• WearBrowserService — implements Android's MediaBrowserService contract (onLoadChildren, onGetRoot, MediaSessionCallback.onPlay/onSeekTo/onPlayFromMediaId) to expose playback to Android Wear/Auto [app/src/main/java/com/naman14/timber/WearBrowserService.java:L87-L126]. This is the closest thing Timber has to an "API" — it's Android's OS-level media browsing contract, not a custom one.
• Last.fm REST client — LastFmRestService and LastFmUserRestService are Retrofit-annotated interfaces (@GET, @POST, @FormUrlEncoded) defining calls to the Last.fm web API for album/artist info and scrobbling [app/src/main/java/com/naman14/timber/lastfmapi/LastFmRestService.java:L25-L39, app/src/main/java/com/naman14/timber/lastfmapi/LastFmUserRestService.java:L17-L30]. This is Timber acting as a client of an external API, not exposing one.
• Small internal listener interfaces like ArtistInfoListener (callback-style, artistInfoSucess/artistInfoFailed) [app/src/main/java/com/naman14/timber/lastfmapi/callbacks/ArtistInfoListener.java:L19-L26].

So Timber's "API" is really a set of internal service classes and Android-framework contract implementations, plus a client for a third-party web API. There's no reusable/public library surface intended for other developers.

scwang90/smartrefreshlayout — a library with a real public API

This is a pull-to-refresh Android library, so it's built explicitly around a public API surface meant for app developers to integrate:

• Its README (both Chinese and English) advertises library-level capabilities as its "features/API": multi-touch support, nested-scroll support for any View (AbsListView, RecyclerView, WebView), pluggable custom Header/Footer components, auto-refresh/auto-load-more, custom interpolators, theme support, over-scroll rebound, AndroidX support [README.md:L26-L43].
• It ships reusable, drop-in UI components such as CircleImageView (from the material header package) [refresh-header-material/src/main/java/com/scwang/smart/refresh/header/material/CircleImageView.java:L1-L33] and a vendored, license-noted PathParser utility adapted from AOSP for path drawables [refresh-drawable-path/src/main/java/com/scwang/smart/drawable/path/PathParser.java:L1-L28].
• The README explicitly documents integration concerns like ProGuard rules, noting the library avoids serialization/reflection/JNI so no obfuscation exceptions are needed [README_EN.md:L249-L252] — a hallmark of designing for external consumers.
• It's licensed under Apache 2.0 [README.md:L338-L360, README_EN.md:L291-L311], reinforcing that it's meant to be embedded in other projects.

I didn't find the actual RefreshLayout/SmartRefreshLayout core interface class (e.g., setOnRefreshListener, setRefreshHeader) in the retrieved chunks — only supporting drawable/header helper classes and README-level feature descriptions surfaced. If you want the exact method signatures of that core public interface, I can search more specifically for it.

Bottom line

• Timber: no real "public API" — it's a self-contained app whose only external-facing contracts are OS-level Android media APIs (`MediaBrow