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/h6ah4i/android-advancedrecyclerview 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

• 3 active contributors
• Apache-2.0 licensed
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 83% of recent commits
• ⚠ No CI workflows detected

_{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 h6ah4i/android-advancedrecyclerview repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/h6ah4i/android-advancedrecyclerview.

What it runs against: a local clone of h6ah4i/android-advancedrecyclerview — 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 h6ah4i/android-advancedrecyclerview | 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 ≤ 1021 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "h6ah4i/android-advancedrecyclerview(\\.git)?\\b" \\
  && ok "origin remote is h6ah4i/android-advancedrecyclerview" \\
  || miss "origin remote is not h6ah4i/android-advancedrecyclerview (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 "build.gradle" \\
  && ok "build.gradle" \\
  || miss "missing critical file: build.gradle"
test -f "library/src/main/java/com/h6ah4i/android/widget/advrecyclerview" \\
  && ok "library/src/main/java/com/h6ah4i/android/widget/advrecyclerview" \\
  || miss "missing critical file: library/src/main/java/com/h6ah4i/android/widget/advrecyclerview"
test -f "example/src/main/java/com/h6ah4i/android/example/advrecyclerview" \\
  && ok "example/src/main/java/com/h6ah4i/android/example/advrecyclerview" \\
  || miss "missing critical file: example/src/main/java/com/h6ah4i/android/example/advrecyclerview"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "RELEASE-NOTES.md" \\
  && ok "RELEASE-NOTES.md" \\
  || miss "missing critical file: RELEASE-NOTES.md"

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

android-advancedrecyclerview is a Java/Android library extending RecyclerView with gesture-driven features: swipe-to-dismiss/swipe-to-reveal (like Google Inbox), drag-and-drop reordering (like Google Play Music), and expandable/collapsible list items. It handles complex touch interactions and item state management that would otherwise require extensive custom code. Standard Android library module: core library code (likely in library/ or advrecyclerview/) providing ViewHolder interfaces (DraggableItemViewHolder, SwipeableItemViewHolder, ExpandableItemViewHolder), example app in example/src/ with separate demo packages (demo_d_basic/, demo_d_minimal/, demo_d_grid/), and doclava documentation generation template for API docs.

Android app developers building feature-rich list UIs who need production-grade implementations of swiping, dragging, and expandable items without writing complex gesture handlers and state machines themselves.

Mature and stable: published on Maven Central (v1.0.0 from December 2018), has migrated to AndroidX, includes a full example app in Google Play, extensive doclava-generated documentation in doclava/template/, and comprehensive release notes. However, last release is ~5 years old with no visible recent commits, suggesting the project is feature-complete but not actively maintained.

Low adoption risk due to API stability and broad version support (API 14+), but dependency risk is moderate: relies on AndroidX recyclerview:recyclerview:1.0.0 (from 2018) which may have security patches in newer versions. Single-maintainer (h6ah4i) with no visible recent activity means bug fixes or critical updates may be slow. No breaking changes since v1.0.0 migration from support libraries.

Project appears dormant: no visible active development, PRs, or milestones. Last tagged release is v1.0.0 (December 2018) with AndoridX migration completing the feature set. The example app is published on Google Play but likely receives minimal updates.

Clone and build with Gradle: git clone https://github.com/h6ah4i/android-advancedrecyclerview.git && cd android-advancedrecyclerview && ./gradlew build. Open in Android Studio; see build.gradle (Gradle 3.2.1, compileSdkVersion 28). To run the example app: ./gradlew :example:assembleDebug then install with adb install example/build/outputs/apk/debug/example-debug.apk.

Daily commands: This is a library, not an executable app, but to verify the build: ./gradlew assemble. To run the bundled example app in an emulator: ./gradlew :example:installDebug && adb shell am start -n com.h6ah4i.android.example.advrecyclerview/.MainActivity (requires Android emulator or device connected via adb).

• build.gradle — Root build configuration defining compileSdkVersion (28), buildToolsVersion, and RecyclerView dependency (1.0.0) that all modules depend on
• library/src/main/java/com/h6ah4i/android/widget/advrecyclerview — Core library package containing the main RecyclerView extension implementations (swiping, drag-drop, expandable features)
• example/src/main/java/com/h6ah4i/android/example/advrecyclerview — Example app demonstrating all advanced RecyclerView features; primary reference for integration patterns
• README.md — Project overview documenting the three core features (Inbox-like swiping, Play Music drag-drop, expandable items) and API level 14+ support
• RELEASE-NOTES.md — Changelog tracking breaking changes, API additions, and feature deprecations across versions
• common/android-maven-publish.gradle — Maven publishing configuration required for library distribution to Maven Central

• Swipeable RecyclerView Listener (RecyclerView.OnItemTouchListener, GestureDetector, VelocityTracker) — Intercepts touch events (left/right motion), calculates swipe offset, triggers item reveal animations, and notifies adapter of swipe actions
  • Failure mode: Touch events misdirected to child views; swipe gestures conflict with vertical scroll; incorrect position tracking if RecyclerView is nested
• **** — undefined

Add a new swipe-enabled list feature

1. Create a new Activity in example/src/main/java/com/h6ah4i/android/example/advrecyclerview/ extending the appropriate demo base class (example/src/main/java/com/h6ah4i/android/example/advrecyclerview)
2. Extend the library's SwipeableRecyclerViewTouchListener (in library/src/main/java/com/h6ah4i/android/widget/advrecyclerview) to handle swipe gestures (library/src/main/java/com/h6ah4i/android/widget/advrecyclerview)
3. Register your new Activity in example/src/main/AndroidManifest.xml with appropriate intent filters (example/src/main/AndroidManifest.xml)
4. Update example/src/main/java/com/h6ah4i/android/example/advrecyclerview/about/AboutActivity.java to include a menu item launching your new feature demo (example/src/main/java/com/h6ah4i/android/example/advrecyclerview/about/AboutActivity.java)

Implement drag-and-drop sortable adapter

1. Create a new Adapter class in the example app extending DemoHeaderFooterAdapter with your data model (example/src/main/java/com/h6ah4i/android/example/advrecyclerview/common/adapter/DemoHeaderFooterAdapter.java)
2. Implement the ItemDraggableSwipeableCallback interface from library/src/main/java/com/h6ah4i/android/widget/advrecyclerview to define drag behavior (library/src/main/java/com/h6ah4i/android/widget/advrecyclerview)
3. Create a TouchEventHandler in your Activity to attach the drag listener to RecyclerView.ItemDecoration (example/src/main/java/com/h6ah4i/android/example/advrecyclerview)
4. Test with the example app by running: ./gradlew example:assembleDebug && adb install example/build/outputs/apk/debug/example-debug.apk (example/build.gradle)

Publish a new library version to Maven Central

1. Update library version in build.gradle root project.ext block (compileSdkVersion, buildToolsVersion, recyclerViewVersion if needed) (build.gradle)
2. Add release notes documenting breaking changes and new features in RELEASE-NOTES.md (RELEASE-NOTES.md)
3. Configure keystore credentials in common/android-signing-utils.gradle (or via CI environment variables) (common/android-signing-utils.gradle)
4. Execute: ./gradlew library:build library:publishMavenPublicationToSonatypeRepository (or equivalent Maven Central upload task defined in common/android-maven-publish.gradle) (common/android-maven-publish.gradle)

• RecyclerView 1.0.0 — Foundation for all list-based UI; supports ItemDecoration and touch listeners needed for swiping and drag-drop
• Android SDK 14+ (minSdkVersion=14, targetSdkVersion=28) — Broad device compatibility (4.0 Ice Cream Sandwich onward) while targeting modern Material Design patterns available in SDK 28
• Gradle 3.2.1 with Android Plugin — Standard Android build toolchain; enables modular library/example split and Maven Central publishing
• Java (not Kotlin) — Legacy codebase predates widespread Kotlin adoption; maintains compatibility with older Android projects

• Library provided as .jar/.aar via Maven Central rather than as source inclusion

  • Why: Simplifies integration for downstream projects; separates library concerns from example code
  • Consequence: Developers cannot easily inspect library internals without downloading source separately; tooling dependency on Maven Central

• RecyclerView 1.0.0 pinned (not androidx migration to 1.x+)

  • Why: Maintains API stability and backward compatibility with minSdkVersion=14 projects
  • Consequence: Cannot use newer RecyclerView features (e.g., ConcatAdapter, async diffing); projects migrating to AndroidX must manage compatibility

• Touch event handling via ItemDecoration and RecyclerView.OnItemTouchListener rather than GestureDetector

  • Why: Direct integration with RecyclerView's layout pass allows precise position tracking and scrolling coordination
  • Consequence: More complex touch state management; harder to reuse for non-RecyclerView contexts

• Example app bundled in same repo rather than separate sample project

  • Why: Ensures example stays in sync with library API changes and serves as integration documentation
  • Consequence: Release build artifacts include unnecessary example code; example code updates trigger library version bumps

• Multi-direction swiping with complex reveal menus (limited to left/right primary actions)
• Nested drag-drop hierarchies or tree-view structure reordering
• Touch event handling for non-RecyclerView layouts (e.g., ListView, custom ScrollViews)
• Real-time synchronization with remote backend (purely local list manipulation)
• Accessibility features beyond standard Android TalkBack support

No unusual env vars or service dependencies. Key constraint: compileSdkVersion 28 and buildToolsVersion 28.0.3 are dated (from 2018); newer Android Studio versions may warn about updating to higher API levels, but minSdkVersion 14 locks backward compatibility. ViewHolder subclasses MUST implement getDragState()/getSwipeState()/getExpandState() in v1.0.0+ (breaking change from v0.11.0) — old code will not compile. The library uses BaseWrapperAdapter pattern which requires careful setup in your existing adapter.

• ViewHolder state machine pattern — This library uses DraggableItemState, SwipeableItemState, and ExpandableItemState interfaces to encapsulate gesture state; understanding how these objects change through ViewHolder lifecycle is essential to building correct item interactions.
• Gesture disambiguation and touch event interception — RecyclerView's standard touch handling must be overridden to detect swipe vs. drag vs. expand gestures without conflicting; this library solves that via custom MotionEvent routing and velocity tracking.
• Adapter wrapping (Decorator pattern) — The BaseWrapperAdapter pattern allows gesture features to wrap an existing RecyclerView.Adapter without modifying it, following the Decorator pattern for backward compatibility.
• Item animation and layout transitions — Swipe reveals, drag reordering, and expand/collapse all require coordinated RecyclerView.ItemAnimator callbacks and LayoutManager updates; this library coordinates those internally.
• Rubber band effect (overscroll simulation) — The removed REACTION_CAN_NOT_SWIPE_BOTH_WITH_RUBBER_BAND_EFFECT constant (v1.0.0 breaking change) used spring-like physics to simulate iOS-style bounce when user swipes past content limits.
• AndroidX migration and support library deprecation — v1.0.0 migrated from android.support.v7.widget to androidx.recyclerview.widget; understanding this breaking change is critical for legacy app integration and explains why v0.11.0 still exists.

• wasabeef/recyclerview-animators — Complementary library providing enter/exit animations for RecyclerView items, often used alongside advanced gesture handling.
• yanzhenjie/SwipeRecyclerView — Alternative Android library focused specifically on swipe gestures for RecyclerView, simpler API but less feature-complete than advrecyclerview.
• androidx/androidx — Official AndroidX library (androidx.recyclerview:recyclerview) that this library depends on and extends.
• h6ah4i/android-verticalseekbar — Same maintainer's companion project (noted in Maven Central badge) — custom Android widget library following same architecture patterns.

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 GitHub Actions CI workflow for automated testing and release

The repo uses Gradle with Android build tools but lacks CI/CD automation. Currently, there's no GitHub Actions workflow to run tests, verify builds, or automate releases. Adding CI would catch regressions early, validate PRs, and streamline the release process for Maven Central publishing (which the README badge indicates is used).

• [ ] Create .github/workflows/android-build.yml to run 'gradle build' and execute unit/instrumentation tests on PR
• [ ] Create .github/workflows/release.yml to automate Maven Central publishing using common/android-maven-publish.gradle and common/android-signing-utils.gradle
• [ ] Add branch protection rules documentation to CONTRIBUTING.md referencing the CI checks
• [ ] Test locally with act or GitHub CLI to verify workflows execute correctly

Migrate doclava documentation generation to Dokka for modern Kotlin/Java docs

The doclava/ folder contains a legacy documentation generator (doclava-1.0.6.jar from ~2014) with heavy template boilerplate (20+ .cs template files). Dokka is the modern standard for Kotlin/Java projects, produces cleaner output, integrates better with current tooling, and requires significantly less configuration. This improves maintainability and documentation quality.

• [ ] Add dokka gradle plugin to build.gradle and configure output format (HTML/Javadoc)
• [ ] Create dokka {} configuration block with custom styling (migrate key CSS from doclava/template/assets/customizations.css)
• [ ] Remove doclava/ directory entirely and update documentation build instructions in README.md
• [ ] Verify generated docs match or exceed the quality of current doclava output by comparing structure and searchability

Add comprehensive unit tests for core swipe and drag-drop gesture handlers

The README highlights 'Google Inbox-like swiping' and 'Play Music-like drag-and-drop' as main features, but the file structure shows no visible test files (no src/test/ or src/androidTest/ directories listed). These gesture-based features are critical and complex; unit tests would ensure reliability, prevent regressions, and document expected behavior.

• [ ] Create src/test/java/ directory and add tests for core swipe gesture recognition logic
• [ ] Create src/androidTest/java/ directory and add instrumentation tests for drag-drop RecyclerView interactions using Espresso
• [ ] Add test cases covering edge cases: rapid swipes, touch cancellation, multi-finger input, and drag-drop on expandable items
• [ ] Update README.md with 'Testing' section explaining how to run tests, and update CONTRIBUTING.md with test coverage expectations for PRs

• Add unit tests for SwipeableItemViewHolder state transitions in library/src/test/ — currently no visible test coverage for swipe reactions (REACTION_CAN_SWIPE_LEFT, etc.) and rubber-band effect edge cases.
• Create a 'Swipe + Expandable combined' example in example/src/main/java/com/h6ah4i/android/example/advrecyclerview/demo_combined/ — README lists drag examples and swipe examples separately but no demo combines both gestures.
• Update doclava documentation templates (doclava/template/*.cs files) to include inline code snippets showing getDragState().isActive() and getSwipeState().getReaction() patterns — current templates are bare.

The codebase has moderate security concerns, primarily related to outdated build infrastructure and dependencies. The project uses a Gradle version from 2018, targets an old Android SDK (API 28 from 2018), and relies on a deprecated repository (jcenter). These factors combined create significant risk exposure to known vulnerabilities and prevent adoption of modern security practices. The minimum SDK of 14 is particularly concerning from a security stand

• High · Outdated Gradle Build Tool — build.gradle (classpath 'com.android.tools.build:gradle:3.2.1'). The project uses Gradle 3.2.1, which is significantly outdated (released in 2018). This version contains known security vulnerabilities and lacks security patches for dependency resolution and build integrity checks. Fix: Update to the latest stable Gradle version (currently 8.x). This will provide security patches, improved dependency verification, and protection against supply chain attacks.
• High · Outdated Android SDK Target — build.gradle (targetSdkVersion = 28). The project targets Android SDK 28 (Android 9.0, released in 2018). Modern Android apps should target API 33 or higher to meet Google Play Store requirements and receive security updates for framework-level vulnerabilities. Fix: Update targetSdkVersion to API 34 or higher. Review and test compatibility with newer Android versions, particularly regarding permissions, storage access, and behavior changes.
• Medium · Outdated Build Tools Version — build.gradle (buildToolsVersion = '28.0.3'). Build Tools version 28.0.3 is outdated. Newer versions contain security patches and improvements to the build process, including better detection of security issues. Fix: Update to Build Tools 34.0.x or the latest available version compatible with your target SDK.
• Medium · Deprecated Repository Configuration — build.gradle (repositories section). The project uses 'jcenter()' repository which has been sunset by JFrog as of May 2021. Relying on deprecated repositories can lead to unavailable dependencies and security risks. Fix: Remove jcenter() and rely solely on 'google()' and 'mavenCentral()' repositories. Verify all dependencies are available in active repositories.
• Medium · Missing Dependency Version Pinning — build.gradle (project.ext block and dependencies). The RecyclerView dependency version is stored in ext.recyclerViewVersion but not all build dependencies are explicitly pinned. This could lead to unexpected version updates with breaking changes or security issues. Fix: Implement strict version management for all dependencies. Consider using a BOM (Bill of Materials) or dependency lock file to ensure reproducible builds.
• Low · Missing ProGuard/R8 Configuration Review — example/proguard-rules.pro. While proguard-rules.pro exists in the example module, without reviewing its contents, there's no confirmation that sensitive code paths are properly protected from reverse engineering. Fix: Review ProGuard/R8 configuration to ensure sensitive classes, methods, and strings are properly obfuscated. Enable R8 (modern replacement for ProGuard) if not already in use.
• Low · Low Minimum SDK Version — build.gradle (minSdkVersion = 14). minSdkVersion = 14 (Android 4.0, released in 2011) is extremely permissive. Supporting such old versions increases the attack surface and prevents use of modern security APIs. Fix: Increase minSdkVersion to at least 21 (Android 5.0) or higher. This allows use of modern security APIs like TLS 1.2+, better cryptography, and secure random number generation.
• Low · No Visible Dependency Security Scanning — build.gradle and project configuration. There is no evidence of dependency scanning tools (OWASP Dependency-Check, Snyk, etc.) configured in the build process to detect known vulnerabilities in transitive dependencies. Fix: Integrate a dependency vulnerability scanner into the CI/CD pipeline. Use tools like 'dependencyUpdates' gradle plugin, OWASP Dependency-Check, or commercial solutions like Snyk.

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.