How do their APIs compare?

At a design level, Dexter and Disruptor solve very different problems, and their APIs reflect that.

karumi/dexter — a fluent, listener-based wrapper API

Dexter's public API is a small fluent builder wrapping an Android permission-check flow. From the README, usage centers on a builder chain:

Dexter.withContext(activity)
    .withPermission(permission)
    .withListener(listener)
    .check();

Key API elements:

• PermissionRequest — a simple wrapper class representing a single permission request [dexter/src/main/java/com/karumi/dexter/listener/PermissionRequest.java:L16-L23].
• PermissionListener (single-permission) — a callback interface with onPermissionGranted, onPermissionDenied, and onPermissionRationaleShouldBeShown methods, taking a PermissionToken and PermissionGrantedResponse/PermissionDeniedResponse [dexter/src/main/java/com/karumi/dexter/listener/single/PermissionListener.java:L16-L26].
• MultiplePermissionsListener — the multi-permission analog, receiving a MultiplePermissionsReport and a PermissionToken for rationale handling [dexter/src/main/java/com/karumi/dexter/listener/multi/MultiplePermissionsListener.java:L16-L26].
• PermissionToken — used to resume the request after showing a rationale dialog (token.continuePermissionRequest()), as shown in the README's Kotlin example [README.md:L205-L244].

This is an event-callback / observer style API: you register listeners, Dexter drives an internal Activity to perform the OS permission dialog, and results come back asynchronously through your listener implementation. It's designed to be simple and declarative for Android developers, hiding Activity lifecycle and onRequestPermissionsResult boilerplate.

lmax-exchange/disruptor — a low-level concurrency/messaging API

Disruptor's API is structured around high-performance, lock-free (or minimally-locking) coordination primitives for a ring buffer, and it's considerably lower-level:

• Sequencer/AbstractSequencer — manages cursor position and gating sequences for producers claiming slots in the ring buffer [src/main/java/com/lmax/disruptor/AbstractSequencer.java:L21-L27].
• MultiProducerSequencer — a concrete sequencer implementation coordinating multiple publisher threads claiming sequence numbers, with special handling of getCursor()/getHighestPublishedSequence semantics [src/main/java/com/lmax/disruptor/MultiProducerSequencer.java:L23-L33].
• SequenceBarrier — coordination barrier tracking the cursor for publishers relative to dependent EventProcessors [src/main/java/com/lmax/disruptor/SequenceBarrier.java:L18-L22].
• WaitStrategy — pluggable strategy interface controlling how EventProcessors wait on the cursor Sequence (spin, block, yield, etc.) [src/main/java/com/lmax/disruptor/WaitStrategy.java:L17-L21].
• AlertException / InsufficientCapacityException — specialized exceptions without filled-in stack traces for performance, used to signal barrier status changes or ring buffer wrap conditions on tryNext() [src/main/java/com/lmax/disruptor/AlertException.java:L17-L23], [src/main/java/com/lmax/disruptor/InsufficientCapacityException.java:L17-L25].
• dsl.Disruptor and ExceptionHandlerSetting — a higher-level DSL layer that lets you wire up EventHandlers and their exception handlers fluently, e.g. disruptorWizard.handleExceptionsIn(eventHandler).with(exceptionHandler) [src/main/java/com/lmax/disruptor/dsl/ExceptionHandlerSetting.java:L17-L29].

Comparison

Aspect	Dexter	Disruptor
Domain	Android runtime permissions	High-throughput inter-thread messaging
API style	Fluent builder + listener callbacks	Low-level s