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/alibaba/ARouter 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.

WAIT — Stale — last commit 3y ago

• 11 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Single-maintainer risk — top contributor 90% 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 alibaba/ARouter repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/alibaba/ARouter.

What it runs against: a local clone of alibaba/ARouter — 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 alibaba/ARouter | 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 develop exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1000 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of alibaba/ARouter. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/alibaba/ARouter.git
#   cd ARouter
#
# 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 alibaba/ARouter and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "alibaba/ARouter(\\.git)?\\b" \\
  && ok "origin remote is alibaba/ARouter" \\
  || miss "origin remote is not alibaba/ARouter (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 develop >/dev/null 2>&1 \\
  && ok "default branch develop exists" \\
  || miss "default branch develop no longer exists"

# 4. Critical files exist
test -f "arouter-api/src/main/java/com/alibaba/android/arouter/launcher/ARouter.java" \\
  && ok "arouter-api/src/main/java/com/alibaba/android/arouter/launcher/ARouter.java" \\
  || miss "missing critical file: arouter-api/src/main/java/com/alibaba/android/arouter/launcher/ARouter.java"
test -f "arouter-api/src/main/java/com/alibaba/android/arouter/core/LogisticsCenter.java" \\
  && ok "arouter-api/src/main/java/com/alibaba/android/arouter/core/LogisticsCenter.java" \\
  || miss "missing critical file: arouter-api/src/main/java/com/alibaba/android/arouter/core/LogisticsCenter.java"
test -f "arouter-api/src/main/java/com/alibaba/android/arouter/facade/Postcard.java" \\
  && ok "arouter-api/src/main/java/com/alibaba/android/arouter/facade/Postcard.java" \\
  || miss "missing critical file: arouter-api/src/main/java/com/alibaba/android/arouter/facade/Postcard.java"
test -f "arouter-annotation/src/main/java/com/alibaba/android/arouter/facade/annotation/Route.java" \\
  && ok "arouter-annotation/src/main/java/com/alibaba/android/arouter/facade/annotation/Route.java" \\
  || miss "missing critical file: arouter-annotation/src/main/java/com/alibaba/android/arouter/facade/annotation/Route.java"
test -f "arouter-api/src/main/java/com/alibaba/android/arouter/core/Warehouse.java" \\
  && ok "arouter-api/src/main/java/com/alibaba/android/arouter/core/Warehouse.java" \\
  || miss "missing critical file: arouter-api/src/main/java/com/alibaba/android/arouter/core/Warehouse.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1000 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~970d)"
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/alibaba/ARouter"
  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).

ARouter is an Android component routing framework that decouples modular apps by routing navigation requests between activities/fragments without direct dependencies. It supports URL scheme parsing, parameter auto-injection, multi-module orchestration, and interceptor chains—enabling Alibaba-scale apps to split into independent feature modules while maintaining seamless navigation. Multi-module Gradle project: arouter-annotation (JVM-only, pure POJOs for @Route/@Autowired/@Interceptor/@Param annotations); arouter-api (runtime router engine); arouter-compiler (annotation processor generating route mappings); app/ (demo app showing all features); module-java, module-kotlin (example feature modules demonstrating inter-module navigation).

Android architects and senior engineers building large modular apps (especially at scale like Alibaba) who need to decouple components, support deep linking, and manage cross-module navigation without creating circular dependencies or god-classes.

Production-ready and actively maintained. The codebase shows 215KB of Java (primary), established Gradle/Groovy build configuration, comprehensive annotation processor infrastructure (arouter-compiler module), and CI workflows (.github/workflows). Given the scale of Alibaba's adoption and the presence of stable core modules (arouter-api, arouter-annotation), this is well-tested enterprise code.

Low risk for the core router logic itself, but moderate risk from annotation processor complexity (arouter-compiler is write-heavy, error-prone territory). The compile-time code generation pattern can cause subtle issues if module names are misconfigured. Heavy reliance on manual @Route and @Autowired annotations means developer discipline is required; inconsistent naming breaks routing silently at runtime.

The repository shows Gradle wrapper validation CI, demo APK (v1.5.2), and support for incremental annotation processing and dynamic route registration. Active maintenance on Kotlin support and IDE plugin (arouter-idea-plugin). Development appears stable rather than feature-rushing—focus on polish, ProGuard compatibility, and multi-dex support.

Clone: git clone https://github.com/alibaba/ARouter.git. Build: cd ARouter && ./gradlew build. Run demo: ./gradlew :app:installDebug && adb shell am start -n com.alibaba.android.arouter.demo/.MainActivity. Core modules: arouter-api and arouter-compiler; use ./gradlew publishToMavenLocal to test locally.

Daily commands: Debug build: ./gradlew :app:assembleDebug. Test: ./gradlew test. Demo APK install: ./gradlew :app:installDebug. For development: open in Android Studio, Gradle will auto-trigger annotation processors; build :arouter-api as library, :arouter-compiler as APT plugin, :app as sample.

• arouter-api/src/main/java/com/alibaba/android/arouter/launcher/ARouter.java — Public API entry point for all routing operations; every developer must understand how to initialize and use ARouter
• arouter-api/src/main/java/com/alibaba/android/arouter/core/LogisticsCenter.java — Core routing engine that resolves routes and manages the route warehouse; critical for understanding how routing decisions are made
• arouter-api/src/main/java/com/alibaba/android/arouter/facade/Postcard.java — Route descriptor object that holds all navigation metadata; essential for understanding the routing flow
• arouter-annotation/src/main/java/com/alibaba/android/arouter/facade/annotation/Route.java — Primary annotation for declaring routes; contributors must understand the annotation contract
• arouter-api/src/main/java/com/alibaba/android/arouter/core/Warehouse.java — In-memory storage for all route metadata loaded at runtime; critical for performance and initialization logic
• arouter-api/src/main/java/com/alibaba/android/arouter/facade/template/IRouteGroup.java — Interface for generated route group classes; defines the contract between annotation processor and runtime
• arouter-api/src/main/java/com/alibaba/android/arouter/launcher/_ARouter.java — Internal routing implementation handling navigation callbacks and interceptor chains; essential for understanding execution flow

Add a new routable Activity

1. Create your Activity class and add @Route annotation with a unique path (app/src/main/java/com/alibaba/android/arouter/demo/MainActivity.java)
2. Define parameters using @Autowired annotations for automatic injection (arouter-annotation/src/main/java/com/alibaba/android/arouter/facade/annotation/Autowired.java)
3. Navigate using ARouter.getInstance().build(path).navigation() (arouter-api/src/main/java/com/alibaba/android/arouter/launcher/ARouter.java)

Create a custom interceptor

1. Implement IInterceptor and add @Interceptor annotation to register (arouter-api/src/main/java/com/alibaba/android/arouter/facade/template/IInterceptor.java)
2. Override process() to inspect/modify postcard before navigation (arouter-api/src/main/java/com/alibaba/android/arouter/core/InterceptorServiceImpl.java)
3. Call callback.onContinue(postcard) to proceed or callback.onInterrupt(throwable) to stop (arouter-api/src/main/java/com/alibaba/android/arouter/facade/callback/InterceptorCallback.java)

Implement a navigation callback

1. Create a NavigationCallback instance with onFound/onLost/onArrival implementations (arouter-api/src/main/java/com/alibaba/android/arouter/facade/callback/NavigationCallback.java)
2. Pass callback to navigation: ARouter.getInstance().build(path).navigation(context, callback) (arouter-api/src/main/java/com/alibaba/android/arouter/launcher/ARouter.java)
3. Inspect the resulting Postcard in onFound() or handle NoRouteFoundException in onLost() (arouter-api/src/main/java/com/alibaba/android/arouter/facade/Postcard.java)

Register a service provider

1. Implement a service interface (IProvider-derived) and add @Route annotation (arouter-api/src/main/java/com/alibaba/android/arouter/facade/template/IProvider.java)
2. Service is auto-discovered and stored in Warehouse during initialization (arouter-api/src/main/java/com/alibaba/android/arouter/core/Warehouse.java)
3. Retrieve via ARouter.getInstance().navigation(YourServiceInterface.class) (arouter-api/src/main/java/com/alibaba/android/arouter/launcher/ARouter.java)

• Annotation Processing (APT) — Compile-time code generation eliminates reflection overhead at runtime and enables static route discovery before app launch
• In-Memory Route Warehouse — Provides O(1) route lookups after initial loading; trading small memory footprint for zero-latency navigation
• Interceptor Chain Pattern — Allows pluggable middleware for cross-cutting concerns (auth, logging, degradation) without modifying core routing logic
• Thread Pool Executor — Enables asynchronous interceptor execution and background operations without blocking main thread
• Generated IRouteGroup/IRouteRoot — Modular route organization per component; each module generates its own group, simplifying incremental loading and multi-module support

• All routes loaded into Warehouse at initialization
  • Why: Fast O(1) lookup and deterministic behavior, but trades startup time for runtime speed
  • Consequence: Large apps with many routes may see slightly slower cold start; mitigated by lazy loading

1. Annotation processor requires AROUTER_MODULE_NAME in javaCompileOptions.annotationProcessorOptions.arguments per module—omit this and route tables won't generate. 2. @Route paths must be unique globally; duplicates cause silent overwrites, second definition wins. 3. Proguard: must keep generated Route___Mapping and Autowired___ classes; include them in proguard-rules.pro via -keep class com.alibaba.android.arouter.routes.** {*;}. 4. Incremental processing can cache stale mappings if module-names clash; full rebuild (./gradlew clean) sometimes required after structural changes.

• Annotation Processing (APT) — ARouter's core mechanism: compile-time code generation via arouter-compiler processes @Route/@Autowired annotations to produce route tables, avoiding reflection overhead at app startup
• Interceptor Chain Pattern — ARouter's @Interceptor mechanism allows middleware (login, analytics, permissions) to wrap navigation—critical for cross-cutting concerns in modular apps without coupling
• Deep Linking & URL Scheme Parsing — ARouter parses arouter:// scheme URIs into internal routes with parameters, enabling external deep links (ads, push notifications) to route to correct app screens
• Compile-time Dependency Injection (Field Injection) — @Autowired enables automatic binding of Intent extras to Activity fields after routing, reducing boilerplate and improving type safety vs. manual getIntent() calls
• Service Locator Pattern — ARouter acts as a centralized registry for routes and service instances; modules query it by path rather than direct imports, enabling loose coupling and swappable implementations
• Incremental Annotation Processing — ARouter's Gradle plugin supports incremental APT (only reprocesses changed modules), critical for large multi-module projects to keep build times under control
• Multi-Dex Support & Class Loading — ARouter dynamically discovers generated route mapping classes across all DEX files, enabling modular apps to avoid method count limits and support large feature sets

• android/architecture-samples — Google's reference architecture for modular Android apps; ARouter is often paired with this pattern for best-practice component isolation
• google/dagger — Complementary dependency injection framework; ARouter handles navigation routing while Dagger handles object graph—many production apps use both together
• ThexXx/ByeBurger — Another Android router focused on simplicity; useful comparison for alternative approach to the same decoupling problem
• alibaba/sofa-ark — Alibaba's dynamic module loading framework; pairs with ARouter to handle runtime module deployment in super-apps
• JetBrains/kotlin — ARouter has first-class Kotlin support; Kotlin's extension functions and sealed classes integrate with ARouter's DSL and route definitions

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 unit tests for arouter-annotation facade models

The arouter-annotation module contains core model classes (RouteMeta.java, TypeWrapper.java) and enums (RouteType.java, TypeKind.java) that lack test coverage. These are fundamental to the routing system and deserve unit tests to catch regressions when modifying annotation processing logic.

• [ ] Create arouter-annotation/src/test/java/com/alibaba/android/arouter/facade/model/RouteMetaTest.java with tests for RouteMeta construction, getters, and serialization
• [ ] Create arouter-annotation/src/test/java/com/alibaba/android/arouter/facade/model/TypeWrapperTest.java testing type wrapping and unwrapping behavior
• [ ] Create arouter-annotation/src/test/java/com/alibaba/android/arouter/facade/enums/RouteTypeTest.java validating enum values map correctly to route destinations
• [ ] Add test task to arouter-annotation/build.gradle if missing

Add integration tests for Autowired dependency injection with various parameter types

The arouter-api module includes AutowiredServiceImpl.java and Autowired.java annotation, but the test coverage for parameter injection across different types (primitives, objects, collections) is unclear from the file structure. The demo app shows basic usage but lacks systematic test cases.

• [ ] Create app/src/androidTest/java/com/alibaba/android/arouter/demo/AutowiredIntegrationTest.java
• [ ] Add test cases for primitive types (int, boolean, String), object injection, and TypeKind enum type conversions using the existing @Autowired annotation
• [ ] Test that InstrumentationHook.java properly intercepts activity creation and triggers AutowiredLifecycleCallback.java
• [ ] Verify parameter injection from Intent extras matches @Param annotation declarations

Add GitHub Actions workflow for running instrumented tests on multiple API levels

The repo has gradle-wrapper-validation.yml but lacks a comprehensive CI workflow for running Android instrumented tests. Given this is a routing framework used in production apps, testing against multiple Android API levels (API 21+) in CI would catch platform-specific issues early.

• [ ] Create .github/workflows/android-instrumented-tests.yml with steps to run connectedAndroidTest on emulators for API levels 21, 28, 29, and latest
• [ ] Configure the workflow to cache Gradle dependencies and Android SDK to reduce build time
• [ ] Add workflow status badge to README.md alongside existing Gitter and license badges
• [ ] Ensure workflow triggers on push to master and pull requests affecting arouter-api, arouter-annotation, or app modules

• Add comprehensive unit tests for arouter-compiler's annotation processor logic (currently no test/ folder visible in arouter-compiler/)—test route deduplication, cyclic dependency detection, and edge cases like empty @Route paths.
• Document migration guide for existing flat apps to modularized ARouter structure: create app-specific examples showing activity decoupling, service inter-module calls, and navigation state preservation across modules.
• Extend demo app with a complete e-commerce scenario (cart module, product module, user module) showing real-world @Interceptor usage for login checks, analytics tracking, and permission gating—current demo is minimal.

The ARouter codebase has several significant security concerns, primarily related to credential management and signing configurations. The most critical issues are: (1) Hardcoded debug keystore credentials committed to the repository, (2) Release builds using debug signing configuration, (3) Outdated Java target version (1.7), and (4) Use of deprecated Support Libraries instead of AndroidX. These vulnerabilities could enable unauthorized app signing, APK tampering, and exposure to known Android/Java security issues. Immediate remediation of credential handling and migration to modern Android development practices is recommended.

• High · Hardcoded Debug Keystore Credentials — app/build.gradle (signingConfigs.debug block) and app/doc/debug/debug.keystore. The debug keystore file (app/doc/debug/debug.keystore) is committed to the repository along with hardcoded credentials (storePassword: 'android', keyPassword: 'android') in the build.gradle file. This allows anyone with repository access to sign APKs with the debug key, potentially enabling app tampering or unauthorized distribution. Fix: 1) Remove the debug.keystore file from version control and add it to .gitignore. 2) Move signing credentials to a secure configuration file outside the repository (gradle.properties in home directory or environment variables). 3) Use a separate debug key for local development that is not committed to the repository.
• High · Debug Signing Config Used for Release Build — app/build.gradle (buildTypes.release.signingConfig). The release build type is configured to use the same debug signing configuration (signingConfig signingConfigs.debug). This means release APKs would be signed with the debug key, which is insecure and violates Android best practices. Fix: Create a separate release signing configuration with proper credentials management. Define release signing separately using environment variables, secure files, or gradle.properties located outside the repository.
• Medium · Insecure Java Compilation Target — app/build.gradle (compileOptions block). The project targets Java 1.7 (JavaVersion.VERSION_1_7) which reached end of life in July 2019 and contains known security vulnerabilities. Modern Android development should target at least Java 8 or higher. Fix: Update compilation target to at least JavaVersion.VERSION_1_8 or higher (VERSION_11 or VERSION_17 recommended). Ensure all dependencies are compatible with the updated target version.
• Medium · Missing or Outdated Support Library Versions — app/build.gradle (dependencies section with SUPPORT_LIB_VERSION variable). The build.gradle references Support Library dependencies (support-v4, appcompat-v7) without showing version constraints. Support Library has been deprecated in favor of AndroidX. Using outdated support libraries may include known security vulnerabilities. Fix: Migrate from Support Library to AndroidX libraries. If Support Library must be used, ensure SUPPORT_LIB_VERSION is set to the latest available version (28.0.0 was the final release).
• Low · Lint Warnings Not Enforced — app/build.gradle (lintOptions block). The configuration contains 'abortOnError false' in lintOptions, which suppresses critical lint errors and allows the build to succeed even with potential security or quality issues detected by Android Lint. Fix: Change 'abortOnError false' to 'abortOnError true' and address all lint warnings and errors. If specific lint checks must be disabled, use explicit disable rules rather than suppressing all errors.
• Low · Minify Not Enabled in Debug Build — app/build.gradle (buildTypes.debug.minifyEnabled = false). While this is standard practice for debug builds, ensure that the release build has minifyEnabled set correctly. Code minification (ProGuard/R8) provides obfuscation which adds a layer of protection against reverse engineering. Fix: This is acceptable for debug builds. Ensure release build maintains 'minifyEnabled true' and proper ProGuard rules are configured (proguard-rules.pro).

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.