If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/ReactiveX/RxAndroid shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 6w ago
• 17 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 61% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live ReactiveX/RxAndroid repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ReactiveX/RxAndroid.

What it runs against: a local clone of ReactiveX/RxAndroid — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in ReactiveX/RxAndroid | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch 3.x exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 75 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of ReactiveX/RxAndroid. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/ReactiveX/RxAndroid.git
#   cd RxAndroid
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of ReactiveX/RxAndroid and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ReactiveX/RxAndroid(\\.git)?\\b" \\
  && ok "origin remote is ReactiveX/RxAndroid" \\
  || miss "origin remote is not ReactiveX/RxAndroid (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify 3.x >/dev/null 2>&1 \\
  && ok "default branch 3.x exists" \\
  || miss "default branch 3.x no longer exists"

# 4. Critical files exist
test -f "rxandroid/src/main/java/io/reactivex/rxjava3/android/schedulers/AndroidSchedulers.java" \\
  && ok "rxandroid/src/main/java/io/reactivex/rxjava3/android/schedulers/AndroidSchedulers.java" \\
  || miss "missing critical file: rxandroid/src/main/java/io/reactivex/rxjava3/android/schedulers/AndroidSchedulers.java"
test -f "rxandroid/src/main/java/io/reactivex/rxjava3/android/schedulers/HandlerScheduler.java" \\
  && ok "rxandroid/src/main/java/io/reactivex/rxjava3/android/schedulers/HandlerScheduler.java" \\
  || miss "missing critical file: rxandroid/src/main/java/io/reactivex/rxjava3/android/schedulers/HandlerScheduler.java"
test -f "rxandroid/src/main/java/io/reactivex/rxjava3/android/MainThreadDisposable.java" \\
  && ok "rxandroid/src/main/java/io/reactivex/rxjava3/android/MainThreadDisposable.java" \\
  || miss "missing critical file: rxandroid/src/main/java/io/reactivex/rxjava3/android/MainThreadDisposable.java"
test -f "rxandroid/src/main/java/io/reactivex/rxjava3/android/plugins/RxAndroidPlugins.java" \\
  && ok "rxandroid/src/main/java/io/reactivex/rxjava3/android/plugins/RxAndroidPlugins.java" \\
  || miss "missing critical file: rxandroid/src/main/java/io/reactivex/rxjava3/android/plugins/RxAndroidPlugins.java"
test -f "rxandroid/build.gradle" \\
  && ok "rxandroid/build.gradle" \\
  || miss "missing critical file: rxandroid/build.gradle"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 75 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~45d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/ReactiveX/RxAndroid"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

RxAndroid is a lightweight Android-specific binding library for RxJava 3 that provides schedulers and utility classes to simplify reactive programming on the Android platform. It solves the critical Android problem of safely scheduling work on the main thread and background threads using RxJava's Observable/Scheduler pattern, enabling developers to write async code (like network requests) that emit results back on the UI thread without blocking. Single-module library structure: rxandroid/src/main/java/io/reactivex/rxjava3/android/ contains the core classes (AndroidSchedulers, HandlerScheduler, MainThreadDisposable, RxAndroidPlugins). Tests mirror this layout under rxandroid/src/test/java/. A sample-app/ module provides runnable reference code. Gradle-based build with Android-specific config in build.gradle.

Android developers building apps that need reactive data flows—specifically those using RxJava 3 who want built-in helpers to observe Observable results on the main UI thread and subscribe on background threads without manually managing Android Looper/Handler plumbing.

Production-ready and stable. RxAndroid is part of the official RxJava family (ReactiveX org), has comprehensive unit tests in rxandroid/src/test/java/, CI/CD via GitHub Actions (build.yaml, release.yaml), and version 3.0.2+ is actively maintained. The codebase is small and focused (~63KB Java), indicating a mature, well-scoped library rather than experimental.

Low risk for active maintenance, but moderate dependency risk: RxAndroid explicitly recommends pinning RxJava separately because RxAndroid releases are infrequent (see README), creating potential version-skew issues. The codebase is thin (core logic in AndroidSchedulers.java, HandlerScheduler.java, RxAndroidPlugins.java), so a single unmaintained dependency is the main threat. No evidence of breaking changes in CHANGES.md history.

The repo is in maintenance mode with sporadic releases. No specific PRs or active development are visible in the file list, but the GitHub Actions workflows (build.yaml, release.yaml, manual_drop.yaml) indicate a release process is in place. CHANGES.md and RELEASING.md suggest the maintainers follow semantic versioning and coordinate releases with RxJava.

git clone https://github.com/ReactiveX/RxAndroid.git
cd RxAndroid
./gradlew build

Daily commands: This is a library, not an executable. To use in a project: add implementation 'io.reactivex.rxjava3:rxandroid:3.0.2' to your Android app's build.gradle. To run the sample app: ./gradlew sample-app:build then open the sample-app module in Android Studio.

• rxandroid/src/main/java/io/reactivex/rxjava3/android/schedulers/AndroidSchedulers.java — Primary entry point providing AndroidSchedulers.mainThread() — the core API that all Android RxJava developers use to schedule work on the main thread.
• rxandroid/src/main/java/io/reactivex/rxjava3/android/schedulers/HandlerScheduler.java — Core scheduler implementation wrapping Android Handler/Looper; handles the actual dispatch of work to background threads or main thread via Android's message queue.
• rxandroid/src/main/java/io/reactivex/rxjava3/android/MainThreadDisposable.java — Base class for disposables that must be cleaned up on the main thread; essential for preventing memory leaks when RxJava subscriptions hold Android references.
• rxandroid/src/main/java/io/reactivex/rxjava3/android/plugins/RxAndroidPlugins.java — Plugin system for intercepting and customizing scheduler creation; allows testing and runtime instrumentation of all Android scheduling behavior.
• rxandroid/build.gradle — Defines RxAndroid library dependencies (RxJava 3) and build configuration; essential for understanding what minimum SDK and runtime dependencies are required.
• README.md — Explains the library's purpose, versioning strategy, and minimal setup; clarifies that this is a thin binding layer for Android-specific scheduling, not a full reactive framework.

• AndroidSchedulers (RxJava 3 Scheduler abstraction, Android Handler/Looper) — Public facade providing factory methods for main thread and custom Looper schedulers
  • Failure mode: IllegalStateException if main Looper is not available; null pointer if custom Looper is null
• HandlerScheduler (Android Handler, Looper; RxJava Worker interface) — Concrete Scheduler implementation that posts Runnables to an Android Looper via Handler
  • Failure mode: Dropped actions if Looper thread dies or Handler is recycled; tasks may not execute if Looper is paused
• MainThreadDisposable — Base class for safe resource cleanup ensuring disposal code always runs on the main thread

Add a new Android Scheduler for a custom Looper

1. Create a new public static method in AndroidSchedulers.java that calls HandlerScheduler.create(looper) (rxandroid/src/main/java/io/reactivex/rxjava3/android/schedulers/AndroidSchedulers.java)
2. Document the new method and add a corresponding test in AndroidSchedulersTest.java (rxandroid/src/test/java/io/reactivex/rxjava3/android/schedulers/AndroidSchedulersTest.java)
3. If custom behavior is needed (e.g., timing), extend HandlerScheduler and override createWorker() or schedule() (rxandroid/src/main/java/io/reactivex/rxjava3/android/schedulers/HandlerScheduler.java)

Add a plugin hook for scheduler customization

1. Add a static field and getter/setter pair in RxAndroidPlugins.java following the existing pattern (e.g., onScheduleMainAction) (rxandroid/src/main/java/io/reactivex/rxjava3/android/plugins/RxAndroidPlugins.java)
2. Call the plugin hook in AndroidSchedulers.java or HandlerScheduler.java before executing the action (rxandroid/src/main/java/io/reactivex/rxjava3/android/schedulers/AndroidSchedulers.java)
3. Write a test in RxAndroidPluginsTest.java verifying the hook is called and can intercept behavior (rxandroid/src/test/java/io/reactivex/rxjava3/android/plugins/RxAndroidPluginsTest.java)

Ensure safe main-thread disposal of RxJava subscriptions

1. Extend MainThreadDisposable and implement the onDispose() method instead of dispose() (rxandroid/src/main/java/io/reactivex/rxjava3/android/MainThreadDisposable.java)
2. Call this custom MainThreadDisposable from HandlerScheduler.createWorker() when wrapping your action (rxandroid/src/main/java/io/reactivex/rxjava3/android/schedulers/HandlerScheduler.java)
3. Add unit tests in MainThreadDisposableTest.java to verify disposal is thread-safe (rxandroid/src/test/java/io/reactivex/rxjava3/android/MainThreadDisposableTest.java)

• RxJava 3 — Provides the reactive composable abstraction layer; RxAndroid is purely a binding that adapts RxJava schedulers to Android's threading model.
• Android Handler & Looper — Only safe way to post work to the main thread in Android; wrapping these is RxAndroid's core responsibility.
• Gradle & Maven Central — Standard build and distribution mechanism for Android libraries; enables seamless integration into Android projects.

• Minimal wrapper layer (no utility operators, no advanced APIs)

  • Why: RxAndroid deliberately avoids duplicating RxJava functionality; it is a thin binding only.
  • Consequence: Users must depend on RxJava 3 separately for all operators and reactive chains. This keeps library maintenance simple but requires users to manage two dependencies.

• Plugin system instead of dependency injection

  • Why: Avoids adding a DI framework as a hard dependency; allows testing and instrumentation without runtime overhead.
  • Consequence: Plugin hooks are static and thread-unsafe by default; developers must manage thread safety manually if installing plugins from multiple threads.

• Main thread scheduler as the primary API surface

  • Why: The most common use case in Android; off-thread work is handled by RxJava's existing scheduler pool.
  • Consequence: Custom Looper support is secondary; users seeking fine-grained control over background threads should use RxJava's schedulers directly.

• Does not provide reactive operators (map, filter, flatMap, etc.) — those come from RxJava.
• Does not handle context lifecycle or Activity destruction — that is the developer's responsibility.
• Does not provide persistence or caching layers — purely a threading bridge.
• Does not replace standard Android concurrency primitives (Thread, AsyncTask, Coroutines) — it is one option among many.

Robolectric required for testing: Unit tests use Robolectric (implied by test structure) to simulate Android Looper/Handler; must run on JVM with Robolectric shadow classes, not bare JUnit. Version mismatch risk: README warns RxAndroid releases lag behind RxJava—pinning only RxAndroid may leave you on outdated RxJava; always explicitly depend on both. Handler thread assumption: HandlerScheduler assumes the Looper is already set up by Android runtime; calling AndroidSchedulers.mainThread() from a non-Android context or before Looper initialization will fail. No multi-Looper scheduler factory: AndroidSchedulers provides no built-in way to create schedulers for secondary Looper threads; you must manually instantiate HandlerScheduler with custom Looper if needed. Java 8 minimum: Source targets Java 1.8 (gradle.properties); older JDK versions will not compile this locally.

• Android Looper and Handler — RxAndroid wraps Android's Handler/Looper abstraction into RxJava Scheduler; understanding Looper's thread-affinity model is essential to grasp why AndroidSchedulers.mainThread() works and why it must run on the main thread
• Scheduler abstraction (RxJava) — RxAndroid's core feature is implementing RxJava's abstract Scheduler class; learning how Scheduler defines work() and scheduleAt() methods helps you understand how HandlerScheduler adapts Android threading to RxJava's contract
• Disposable pattern (resource cleanup) — MainThreadDisposable implements RxJava's Disposable to provide a cancellation/cleanup contract; critical for preventing memory leaks when UI is destroyed while async tasks are pending
• Plugin pattern for dependency injection — RxAndroidPlugins allows test code to swap out scheduler implementations at runtime; this is how unit tests avoid requiring Android runtime while still testing RxAndroid behavior
• subscribeOn() vs observeOn() in RxJava — RxAndroid's main use case is observeOn(AndroidSchedulers.mainThread()); understanding the difference between subscribeOn (source threading) and observeOn (emission threading) is essential to use RxAndroid correctly and avoid common threading bugs
• Robolectric testing framework — RxAndroid's test suite uses Robolectric to simulate Android components (Looper, Handler, MainThread) without an emulator; understanding Robolectric's shadow classes is necessary to extend or modify RxAndroid tests
• Thread-safe lazy initialization (instance holder pattern) — AndroidSchedulers.mainThread() uses lazy initialization to create a single Looper instance; the thread-safe singleton pattern here prevents race conditions in scheduler factory methods

• ReactiveX/RxJava — The core RxJava 3 library that RxAndroid depends on; contains Observable, Scheduler, and Disposable abstractions that RxAndroid extends for Android
• ReactiveX/RxKotlin — Kotlin-specific bindings for RxJava 3; companion library if your Android app uses Kotlin instead of Java
• Kotlin/kotlinx.coroutines — Modern alternative to RxJava for async/reactive code on Android; uses Kotlin suspend functions instead of Observable chains; increasingly preferred for new Android projects
• square/retrofit — HTTP client library frequently used with RxJava on Android to emit Observable-wrapped API calls; commonly paired with RxAndroid for main-thread result observing
• ReactiveX/RxAndroid-Old — Historical RxAndroid 2.x versions (now archived); useful reference if you maintain legacy Android apps and need version migration guidance

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive tests for HandlerScheduler edge cases and thread safety

HandlerScheduler.java is a critical component for scheduling on Android's main thread, but HandlerSchedulerTest.java lacks coverage for edge cases like handler disposal during task execution, concurrent scheduling, and looper state transitions. This is high-value because incorrect scheduler behavior can cause subtle Android app crashes and memory leaks.

• [ ] Review HandlerScheduler.java for all public methods and edge cases
• [ ] Add tests in HandlerSchedulerTest.java for: handler.quit() during scheduling, multiple concurrent scheduleXXX calls, disposal during task execution
• [ ] Add tests for looper state changes (quit, restart) and verify no tasks execute after looper death
• [ ] Add stress tests with RxAndroidPlugins to verify thread-safety under load

Add integration tests for AndroidSchedulers with real Robolectric looper scenarios

AndroidSchedulersTest.java currently exists but the test suite is minimal. There's a companion test file RxAndroidPluginsNoRobolectricTest.java which suggests gaps in looper testing without the Robolectric framework. Adding realistic Android lifecycle scenarios (main thread available, main thread blocked, looper not initialized) would catch real-world integration issues.

• [ ] Examine existing AndroidSchedulersTest.java and RxAndroidPluginsNoRobolectricTest.java to understand current coverage gaps
• [ ] Add Robolectric-based tests for: uninitialized looper states, main thread becoming unavailable, rapid looper creation/destruction
• [ ] Add integration tests combining AndroidSchedulers.mainThread() with actual RxJava operators (map, flatMap, etc.)
• [ ] Test interaction with RxAndroidPlugins.setInitHandler() in realistic scenarios

Add missing documentation and examples for RxAndroidPlugins customization in README.md

RxAndroidPlugins.java exists and is tested, but README.md makes no mention of the plugin system for customizing scheduler behavior. This is valuable for advanced users who need to inject test schedulers or customize handler creation. The file structure shows sample-app/src/main/java but no plugin examples.

• [ ] Review RxAndroidPlugins.java for all public static methods (setInitHandler, setSchedulersHandler)
• [ ] Add 'Advanced Usage' section to README.md with code examples for: injecting test schedulers in unit tests, customizing handler creation
• [ ] Create a sample in sample-app demonstrating RxAndroidPlugins.setInitHandler() for testing or custom thread management
• [ ] Document the plugin initialization lifecycle and when handlers are called relative to scheduler creation

• Add unit tests for edge case in MainThreadDisposable.isDisposed(): the test suite (MainThreadDisposableTest.java) does not appear to cover race conditions between disposal and pending Handler.post() calls—writing a test that disposes while a task is enqueued would strengthen reliability verification.: Low risk, high learning value: tests the concurrency model without modifying core logic
• Expand HandlerSchedulerTest.java with a test for schedulePeriodically() behavior: the existing tests focus on one-shot scheduleAt() calls, but the periodic scheduler behavior under main-thread blocking or Looper edge cases lacks coverage.: Moderate complexity, directly improves test coverage of a public Scheduler method
• Add JavaDoc examples to AndroidSchedulers.mainThread() showing typical Observable chains (e.g., subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread())) and warning users about the RxJava version pinning requirement mentioned in README.: Non-code contribution that bridges the gap between README and API docs; improves developer experience

RxAndroid codebase has moderate security concerns primarily related to outdated tooling and dependencies. The most critical issues are the outdated Android Gradle Plugin (4.2.2), old compileSdkVersion (31), and very low minSdkVersion (9). These create significant security gaps by missing modern Android security features and fixes. The gradle-maven-publish-plugin is also outdated. No injection vulnerabilities, hardcoded secrets, or infrastructure misconfigurations were detected in the visible code structure. The core library code appears architecturally sound. Immediate action should focus on updating the Android Gradle Plugin, bumping SDK versions, and reviewing the gradle wrapper configuration.

• High · Outdated Android Gradle Plugin — build.gradle (classpath 'com.android.tools.build:gradle:4.2.2'). The build.gradle uses Android Gradle Plugin version 4.2.2, which is significantly outdated. This version was released in 2021 and no longer receives security updates. Outdated build tools may contain known vulnerabilities that could be exploited during the build process or introduce insecure dependencies. Fix: Update to the latest stable version of Android Gradle Plugin (currently 8.x or 7.x). Review release notes for breaking changes and test thoroughly after upgrading.
• High · Outdated Compile SDK Version — build.gradle (compileSdkVersion = 31). The project targets compileSdkVersion 31, which was released in 2021. Using outdated SDK versions means missing out on critical security patches and latest Android security features (e.g., improved permissions handling, security hardening). Fix: Update compileSdkVersion to the latest available SDK version (currently 34+). Ensure minSdkVersion remains appropriate for your target audience.
• Medium · Low Minimum SDK Version — build.gradle (minSdkVersion = 9). The minSdkVersion is set to 9 (Android 2.3, released 2011). Supporting such old versions extends the security attack surface significantly, as these old platforms lack modern security protections and will never receive security patches. Fix: Evaluate business requirements and consider raising minSdkVersion to at least API 21+ (Android 5.0, 2014). This reduces exposure to ancient, unpatched vulnerabilities and allows use of modern security APIs.
• Medium · Outdated Gradle Maven Publish Plugin — build.gradle (classpath 'com.vanniktech:gradle-maven-publish-plugin:0.18.0'). The gradle-maven-publish-plugin version 0.18.0 is outdated (released mid-2021). This plugin handles publishing artifacts and may contain vulnerabilities related to repository communication or artifact signing. Fix: Update to the latest stable version of gradle-maven-publish-plugin. Check the plugin's GitHub releases for security-related updates.
• Medium · Potential Gradle Wrapper Security — gradle/wrapper/gradle-wrapper.properties. While gradle-wrapper.jar is present, there's no visible checksum verification configuration in the provided build files. Gradle wrappers should have SHA-256 checksums to prevent MITM attacks or compromised wrapper versions. Fix: Verify that gradle-wrapper.properties includes distributionSha256Sum. Run 'gradle wrapper --gradle-version X.X.X' to regenerate with checksums, or manually add the SHA-256 hash.
• Low · No SNAPSHOT Prevention in Release Workflow — .github/workflows/release.yaml. The repository includes a release.yaml workflow file, but from the file structure, it's unclear if there are safeguards preventing accidental release of SNAPSHOT dependencies, which could introduce unpredictable behavior. Fix: Review release workflow configuration to ensure it validates that no SNAPSHOT dependencies are included in release builds. Implement pre-release checks.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.