# AndroidEventBus's roadmap admits its own concurrency bugs by name > AndroidEventBus is a Java event bus for Android built on the observer pattern, with register and unregister plus a Subscriber annotation carrying a tag and a thread mode. Its README spends most of its length on a three month roadmap whose first item is fixing nested dispatch and sticky event consistency. **hehonghui/AndroidEventBus** — A lightweight eventbus library for android, simplifies communication between Activities, Fragments, Threads, Services, etc. - Repository: https://github.com/hehonghui/AndroidEventBus - Stars: 1,606 · Forks: 390 - Language: Java - License: Apache-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/hehonghui-androideventbus ## The observer pattern with three extra decisions The architecture section describes something recognisable and slightly modified. Objects that need to receive events register into the EventBus through a register function, and their subscription methods and subscription objects are stored in a map. When a user posts an event somewhere, the EventBus finds the corresponding subscription object by matching the parameter type and the tag of the event, then executes the method on that object. What makes it more than a plain observer is that three choices are made per subscriber instead of one. The first is the event type, taken from the method parameter. The second is the tag, described as marking receivable types of events just like designating an action in a BroadcastReceiver, which is the comparison the README uses for precision. The third is the thread mode, and it has the granularity that makes the library usable in an Android app. A subscriber with no mode set runs on the UI thread. A subscriber tagged with a specific tag and mode set to POST executes on the same thread as the one where the post function was called. A subscriber with mode set to ASYNC executes on an independent thread, and the example prints the thread name to show that it differs from the caller's. The tag and the mode are independent. The README shows a plain Subscriber method with a default tag, a method with a tag and no mode, and then the same tag combined with each of the two modes, so the same event type can be delivered on different threads to different subscribers. ## Registration is manual in both directions The code example opens with the lifecycle contract rather than with the annotation, and the contract is two calls in two callbacks. An Activity calls EventBus.getDefault().register(this) at the end of onCreate, and calls EventBus.getDefault().unregister(this) at the start of onDestroy, with a comment in the source reminding the developer not to forget the unregister call. ```java EventBus.getDefault().register(this); EventBus.getDefault().unregister(this); ``` That is the whole lifecycle story in the visible documentation. There is no automatic registration tied to the Activity or Fragment lifecycle, because the November 2026 roadmap lists automatic subscriber registration and unregistration, plus Fragment view lifecycle support, as items still to do. The failure mode that follows from this design is the classic one. A registered object that is never unregistered stays in the map, and if it holds a reference to a destroyed Activity, it is a leak that the garbage collector cannot clean up because the bus still holds the subscription. The Subscriber annotation also does not imply a weak reference, and the October 2026 list includes reviewing weak-reference behavior and lifecycle guarantees, which suggests the current behaviour is not something the maintainer considers settled. If you adopt this in a large app, the first thing to enforce in review is the pairing of register and unregister in every subscriber class, because nothing in the library will do it for you. ## Three releases of planned work, none of it shipped The roadmap is the most substantial part of this README and it is honest in a way most library READMEs are not. Everything on it is unchecked. October 2026, version 1.1.0, is titled Core Stability and its items are bug fixes rather than features: nested event dispatch and event queue consistency, singleton initialization and concurrency safety, sticky event concurrency and retention, duplicate event delivery caused by interface inheritance, subscriber identity and registration management, weak-reference behavior and lifecycle guarantees, event matching cache invalidation, unit tests for event delivery, threading and inheritance, and GitHub Actions for automated builds and tests. The stated goal is a stable, predictable, well tested event dispatching core. November 2026, version 1.2.0, covers platform work: optional AndroidX Lifecycle integration, automatic registration and unregistration, Fragment view lifecycle support, Kotlin Flow extensions, configurable event executors and new threading modes, improved sticky event APIs, configurable exception handling, lazy initialization and graceful shutdown of background dispatchers, updated Android build tooling, and Java, Kotlin and Jetpack Compose examples. December 2026, version 1.3.0, is about performance and process: cached subscriber method metadata, optional KSP-based subscriber indexing, R8 and ProGuard compatibility, optional delivery diagnostics, benchmark tests and performance regression tracking, better documentation and migration guides, Maven Central publishing, and improved issue templates and release automation. A library with no GitHub releases, an APK-based app/ directory in the repository, and Maven Central publishing still three months out is being developed outside the normal distribution channels. ## The design principles constrain the roadmap Six principles are stated, and they explain why the fixes come before the features. Lightweight by default means keeping the core library small and avoiding unnecessary dependencies, which is why every modern integration on the roadmap is optional. Backward compatibility means preserving existing public APIs whenever possible, so the changes are additive. Optional integrations is the rule that lifecycle, Kotlin, Flow and compiler integrations stay optional rather than becoming required. Predictable behavior is the one with teeth: event delivery, thread scheduling and subscriber lifecycle rules must be clearly documented. That is what October's cache invalidation and identity items are about, since a matching cache that returns a stale subscriber set is precisely an unpredictable delivery rule. Reliability first states that correctness and automated testing take priority over new features, and that is the order the roadmap follows: no unit tests exist yet, so they are the first item in the first release. Open development means tracking progress through GitHub Issues, pull requests and releases, which for a project with no releases is the part to watch. The vision statement adds one constraint that matters for existing users: modernize into a lifecycle-aware event bus while preserving the simplicity and flexibility of the existing Java API. Backward compatibility is a promise, not an aspiration, which is convenient for anyone already using it. ## Adoption, licensing and where it stops being a good fit The README lists the apps that adopted it, several of them Chinese market applications, among them Accupass, a calendar application shipped on Meizu phones, and an OA application from a fund management company. That list is evidence the library has been used in shipping applications over years, which is a different kind of signal from a stars count. The licence is Apache-2.0, with LICENSE at the repository root alongside README.md and a Chinese README. The repository structure is a single-module Gradle project with lib/ and library/ directories, an app/ directory for a sample application, build.gradle at the root and no settings.gradle complexity. The last push was on 2026-10-15. Where this is the wrong tool is now fairly clear. A new Android project in Kotlin should use the architecture the roadmap describes as future work, not an annotation-driven bus with manual registration. A project that needs lifecycle safety will leak Activities until November 2026 at best. And a project that cares about delivery correctness should read the October list first, because duplicate delivery through interface inheritance is a documented open bug, and a bus that delivers twice is worse than no bus at all. The legitimate case is an existing Java codebase that already uses this library and needs the fixes, or a team that wants to replace hand-rolled callback plumbing with something tagged and thread-aware in a controlled migration. ## Conclusion AndroidEventBus fits an existing Java Android codebase that already couples components through ad hoc callbacks and wants one mechanism with tags and thread modes instead. It is a poor fit for a new project in 2026, because the README lists automatic subscriber registration, AndroidX lifecycle integration and Kotlin Flow extensions as future work for November 2026 rather than shipped features. Before adopting it, read the October 2026 checklist, because nested event dispatch, sticky event concurrency and duplicate delivery caused by interface inheritance are named as open bugs rather than hypothetical ones. ## FAQ ### How do I register a subscriber with AndroidEventBus? Call EventBus.getDefault().register(this) in onCreate and EventBus.getDefault().unregister(this) in onDestroy, then mark the receiving methods with the Subscriber annotation. The README's source comment stresses not forgetting the unregister call. ### What thread modes does AndroidEventBus support? A subscriber with no mode runs on the UI thread. ThreadMode.POST runs the subscriber on the same thread that executed the post, and ThreadMode.ASYNC runs it on an independent thread. The tag is specified separately from the mode. ### Is automatic subscription registration available yet? Not according to the roadmap. Automatic subscriber registration and unregistration, Fragment view lifecycle support and optional AndroidX Lifecycle integration are listed as November 2026 items for version 1.2.0, all unchecked. ### What licence is AndroidEventBus released under? Apache-2.0, with the LICENSE file at the repository root. The project publishes no GitHub releases, and Maven Central publishing is listed on the December 2026 roadmap. ## Sources - [hehonghui/AndroidEventBus on GitHub](https://github.com/hehonghui/AndroidEventBus) - [Issues](https://github.com/hehonghui/AndroidEventBus/issues) - [License: Apache-2.0](https://github.com/hehonghui/AndroidEventBus/blob/master/LICENSE) - [README](https://github.com/hehonghui/AndroidEventBus/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hehonghui-androideventbus