How do their APIs compare?

These two projects operate at very different levels and serve very different purposes, so their "APIs" aren't really comparable in a head-to-head sense — but let me break down what each actually offers.

openzipkin/zipkin: a distributed tracing system with HTTP/wire APIs and a Java core library

Zipkin's "API" surface is mostly about data collection and query, not a language-level API for building UI logic like RxAndroid. Key pieces:

• Core library API (zipkin/src/main/java/zipkin2): Java classes like Endpoint, Span, and SpanBytesEncoder for constructing and encoding trace spans. Example usage builds an Endpoint, attaches it to a Span with trace ID, timestamps, duration, and tags, then encodes it via SpanBytesEncoder.JSON_V2.encode(span) [README.md:L78-L103].
• Collector wire protocols: Zipkin accepts spans over multiple transports (HTTP, Kafka, ActiveMQ, gRPC, RabbitMQ, Pulsar per the README), and also legacy protocols like Scribe via Thrift, seen in ScribeInboundHandler which bridges Thrift-based Scribe log entries into Armeria HTTP services [zipkin-collector/scribe/src/main/java/zipkin2/collector/scribe/ScribeInboundHandler.java:L1-L34].
• Test-support API: zipkin-junit5's ZipkinExtension emulates the v1/v2 POST HTTP APIs for integration testing, including simulating failures via enqueueFailure and counters like httpRequestCount() and collectorMetrics() [zipkin-junit5/README.md:L1-L59], with helpers like HttpFailure for injecting failure scenarios [zipkin-junit5/src/main/java/zipkin2/junit5/HttpFailure.java:L1-L15].

So Zipkin's API is about producing, encoding, transporting, and querying trace data across a server/instrumentation boundary.

reactivex/rxandroid: a small scheduler-integration API for RxJava on Android

RxAndroid's API is much narrower and purely a Java/Android library API — no network or wire protocol involved. It has two central classes:

• AndroidSchedulers: exposes mainThread() — a Scheduler that posts work to the Android main Looper — plus from(Looper) and from(Looper, boolean async) to build schedulers for arbitrary loopers, with async message handling for API 16+ [rxandroid/src/main/java/io/reactivex/rxjava3/android/schedulers/AndroidSchedulers.java:L25-L92].
• RxAndroidPlugins: a hook/plugin API (setInitMainThreadSchedulerHandler, setMainThreadSchedulerHandler, onMainThreadScheduler, reset()) that lets you intercept and override scheduler creation, primarily for testing [rxandroid/src/main/java/io/reactivex/rxjava3/android/plugins/RxAndroidPlugins.java:L24-L115].

This is a thin integration layer over RxJava 3's Scheduler abstraction, letting Android apps route reactive streams onto the main thread safely.

Summary comparison

Aspect	zipkin	rxandroid
Scope	Distributed system: server, collectors, storage, UI, wire APIs	Single-purpose library: scheduler binding for RxJava on Android
API type	HTTP/Thrift/Kafka wire protocols + Java encoding library	Java-only API (Scheduler, plugin hooks)
Consumers	Services instrumented via tracers (e.g., Brave), Zipkin server, UI	Android apps using RxJava
Testability hooks	ZipkinExtension (JUnit5), HttpFailure for simulating HTTP failures	RxAndroidPlugins for injecting test schedulers

In short, Zipkin's API is a distributed-systems, multi-protocol surface for shipping and querying tracing data, while RxAndroid's API is a minimal, single-class scheduler-provider surface for thread management in reactive Android apps.

FOLLOW_UPS:

• How does Zipkin's collector hand