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/scwang90/SmartRefreshLayout 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 1y ago

• 8 active contributors
• Apache-2.0 licensed
• Tests present
• ⚠ Stale — last commit 1y ago
• ⚠ Concentrated ownership — top contributor handles 52% 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 scwang90/SmartRefreshLayout repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/scwang90/SmartRefreshLayout.

What it runs against: a local clone of scwang90/SmartRefreshLayout — 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 scwang90/SmartRefreshLayout | 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 main exists | Catches branch renames | | 4 | Last commit ≤ 550 days ago | Catches sudden abandonment since generation |

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

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

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

SmartRefreshLayout is an Android pull-to-refresh framework that provides intelligent, gesture-driven refresh and load-more functionality with support for nested view hierarchies, over-scroll bouncing, and dozens of built-in animated header/footer styles. It inherits from ViewGroup (not FrameLayout) to handle complex layouts including RecyclerView, ListView, WebView, and custom scrollable views across multiple nesting levels. Monorepo structure: app/ is the sample application containing activities organized by feature (examples/, practice/, style/). Core library likely resides in refresh-header/ and refresh-footer/ modules (referenced as implementation project(...) in build.gradle). The app module handles demo/testing; the header/footer modules encapsulate reusable refresh UI components.

Android app developers building consumer-facing mobile applications (e.g., social feeds, e-commerce, news apps) who need production-ready pull-to-refresh and infinite scroll without building animation and gesture handling from scratch. Also targets design-focused teams wanting highly customizable, visually impressive refresh UI patterns (Taobao second-floor style, phoenix animations, etc.).

Mature and stable. The library has been published to Maven Central with version 3.0.0, supports minSdk 12+, and includes 784 methods across 121 KB. The example app (app/src/main) contains 50+ activity examples covering all patterns. However, no visible CI/CD pipeline (no .github/workflows/) and commit recency is not provided in the data, so recent maintenance status is unclear.

Low-to-moderate risk for production use. The single-file monorepo structure (app/ + refresh-header/ + refresh-footer/ modules) means changes to core layout logic could affect all consuming apps. No test coverage visible in the file list (only one androidTest file: ExampleInstrumentedTest.java), and no automated CI pipeline shown, which increases regression risk. Dependency on AndroidX Material (com.google.android.material:material:1.12.0) and RenderScript (deprecated) suggests maintenance burden.

No concrete PR, issue, or commit data provided, but the repo structure suggests active maintenance of example activities (50+ activity classes covering BasicExample, CustomExample, NestedLayoutExample, OverScrollExample, etc.). The presence of Android SDK 34 (compileSdkVersion) and Material 1.12.0 indicates ongoing updates for latest Android platform versions.

Clone and build:

git clone https://github.com/scwang90/SmartRefreshLayout.git
cd SmartRefreshLayout
./gradlew build
./gradlew :app:installDebug

The debug keystore is already committed (app/debug.keystore) for unsigned APK signing.

Daily commands:

./gradlew :app:assembleDebug
./gradlew :app:installDebug
adb shell am start -n com.scwang.refresh.layout.app/.activity.IndexMainActivity

Or import into Android Studio and Run → Run 'app'.

• app/src/main/AndroidManifest.xml: Declares all 50+ activity examples and defines app entry point (IndexMainActivity); essential for understanding available demos and modifying activity routing.
• app/build.gradle: Defines minSdk, targetSdk, compile targets (Java 8, SDK 34), dependencies (Material, AndroidX), and signing config for debug builds; critical for build compatibility and dependency management.
• app/src/main/java/com/scwang/refresh/layout/activity/example/BasicExampleActivity.java: Canonical example showing minimal SmartRefreshLayout usage (pull-to-refresh + load-more); starting point for understanding the public API.
• app/src/main/java/com/scwang/refresh/layout/activity/NestedLayoutExampleActivity.java: Demonstrates the 'smart' nested view hierarchy support (LinearLayout, FrameLayout, RecyclerView nesting); differentiator feature of this library.
• app/proguard-rules.pro: Defines ProGuard/R8 obfuscation rules for release builds; important for maintaining reflective API access and performance in production APKs.
• app/src/main/java/com/scwang/refresh/layout/activity/practice/: Contains real-world integration patterns (WebViewPracticeActivity, WeiboPracticeActivity, QQBrowserPracticeActivity) showing how to use SmartRefreshLayout in production scenarios.

New refresh animation: Create a class in refresh-header/src/main/java/ extending the base header, then add a corresponding Activity in app/src/main/java/com/scwang/refresh/layout/activity/style/. New gesture logic: Modify core pull/drag handlers in the ViewGroup subclass (likely in refresh-header/ or refresh-footer/). Example activities: Add a new Activity class to app/src/main/java/com/scwang/refresh/layout/activity/example/ and register in AndroidManifest.xml.

RenderScript deprecation: Build uses renderscriptTargetApi 25 and renderscriptSupportModeEnabled true, which is deprecated in recent NDK versions and may fail on Android 12+. No unit/integration tests: Only one androidTest file visible; no src/test/ directory, so regression testing must be manual via APK installation. Hardcoded debug keystore: Committed to repo (app/debug.keystore); ensure it's excluded from production builds. Module dependencies: Implementation uses project(':refresh-header') and project(':refresh-footer'), implying these modules must exist and compile or the app will fail to build.

• Nested Scrolling (Android NestedScroll API) — SmartRefreshLayout's core 'smart' feature is supporting multiple levels of nested scrollable views; understanding the NestedScrollingParent/Child contract is essential for debugging scroll conflicts and coordinating with CoordinatorLayout.
• ViewGroup Custom Layout & Measurement — SmartRefreshLayout inherits from ViewGroup, not FrameLayout, requiring custom onMeasure() and onLayout() logic to handle header/footer positioning and child view bounds; this is why it outperforms simpler wrappers.
• Gesture Detection & Touch Event Flow — Pull-to-refresh requires intercepting MotionEvents, computing velocity/displacement, and deciding when to consume vs. delegate to children; multi-touch support (mentioned in README) adds complexity.
• Over-Scroll Behavior & Bounce Animation — SmartRefreshLayout supports 'over-scroll bouncing' (dragging past list bounds with elastic recoil); this requires custom physics simulation and interpolation to animate smoothly back to rest.
• View Animation Interpolation — The library supports 'custom interpolators for rebound animation' (from README); dozens of header/footer styles (Phoenix, FlyRefresh, Bezier, etc.) depend on frame-by-frame interpolation and custom drawable rendering.
• Drawable & Canvas Rendering — Many built-in header animations (BezierCircle, BezierRadar, DropBox, DeliveryStyle) use custom Canvas drawing for smooth, scalable refresh UI; RenderScript usage (deprecated) suggests prior GPU acceleration attempts.
• State Machine Pattern (Refresh Lifecycle) — Pull-to-refresh implements implicit state machine: Idle → Pulling → ReadyToRefresh → Refreshing → Done; managing transitions, preventing re-entrance, and coordinating with nested scrolls requires careful state design.

• android/architecture-samples — Official Android guidance on ViewModel, LiveData, and view state management patterns, complementary to SmartRefreshLayout's gesture/animation logic.
• android/compose-samples — Jetpack Compose examples demonstrating modern Android UI patterns; relevant for understanding how SmartRefreshLayout might evolve to Compose-native refresh handling.
• liaohuqiu/android-Ultra-Pull-To-Refresh — Predecessor library explicitly cited in README as inspiration; comparison helps understand SmartRefreshLayout's advantages (nested view support, header/footer composability).
• lcodecorex/TwinklingRefreshLayout — Contemporary competitor refresh layout library mentioned in README; useful for benchmarking animation smoothness and API design decisions.
• scwang90/SmartRefreshHorizontal — Official sibling repo extending SmartRefreshLayout to horizontal (left/right) refresh; demonstrates modular architecture and extension 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 instrumented tests for NestedScroll behavior across API levels

The repo has numerous nested scroll examples (NestedScrollExampleFragment, NestedScrollExampleFragmentViewPager, NestedLayoutExampleActivity) but only one instrumented test file (ExampleInstrumentedTest.java). The core SmartRefreshLayout's nested scroll handling is complex and critical for the library's value proposition. Adding comprehensive instrumented tests would catch regressions when updating targetSdkVersion (currently 34) and ensure compatibility across minSdkVersion 21+.

• [ ] Create app/src/androidTest/java/com/scwang/refresh/NestedScrollInstrumentedTest.java
• [ ] Add tests for nested RecyclerView with SmartRefreshLayout behavior
• [ ] Add tests for ViewPager2 nested scroll scenarios from NestedScrollExampleFragmentViewPager.java
• [ ] Add tests verifying overScroll and bounce-back with nested children (OverScrollExampleActivity pattern)
• [ ] Test BottomSheetExampleFragment interaction with SmartRefreshLayout

Add unit tests for BaseRecyclerAdapter and SmartViewHolder

The adapter utilities (app/src/main/java/com/scwang/refresh/layout/adapter/) lack unit test coverage. These are utility classes used across all example activities and are foundational for demonstrating proper SmartRefreshLayout usage. Unit tests would ensure the adapter binding logic is robust and help contributors understand expected behavior.

• [ ] Create app/src/test/java/com/scwang/refresh/layout/adapter/SmartViewHolderTest.java
• [ ] Create app/src/test/java/com/scwang/refresh/layout/adapter/BaseRecyclerAdapterTest.java
• [ ] Add tests for SmartViewHolder binding with different data types
• [ ] Add tests for BaseRecyclerAdapter dataset mutations and notify methods
• [ ] Add tests for edge cases (empty lists, null items, view recycling)

Create GitHub Actions CI workflow to verify all example activities compile and run on emulator

The repo has 16+ example activities and 12+ style demonstration activities across app/src/main/java/com/scwang/refresh/layout/activity/. There is no visible CI workflow (only FUNDING.yml exists in .github/). A workflow that builds the app and runs a smoke test on the main IndexMainActivity would catch compilation breakage early when dependencies or targetSdkVersion change, and validate that all the showcase examples remain functional.

• [ ] Create .github/workflows/build-and-test.yml
• [ ] Configure workflow to run on push to main branch and pull requests
• [ ] Add gradle build step for app module (./gradlew assembleDebug)
• [ ] Add Android Emulator test step to launch IndexMainActivity and verify no crashes
• [ ] Configure matrix strategy to test on API 21 (minSdkVersion) and API 34 (targetSdkVersion)

• Add JUnit4 unit tests for gesture state transitions in the core ViewGroup (e.g., pull → drag → release → bounce-back) under app/src/test/; currently no src/test/ directory exists and gesture logic is untested.
• Create a Javadoc comment template and document the public API of refresh-header/ and refresh-footer/ modules; the file list shows 50+ example activities but no API docs, making it hard for contributors to understand base classes.
• Migrate RenderScript calls to Renderscript Intrinsics or standard Android Canvas APIs to support Android 12+ without deprecation warnings; currently renderscriptTargetApi 25 is hardcoded and may break on newer platforms.

The codebase shows several security concerns, primarily related to credential management and build configuration. The most critical issues are hardcoded debug keystore credentials in version control and the improper use of debug signing for release builds. The incomplete dependency declaration and disabled lint checking are additional concerns that reduce code quality and security oversight. Overall, the project requires immediate attention to secure credential handling and build configuration before being suitable for production release.

• High · Hardcoded Debug Keystore Credentials — app/build.gradle - signingConfigs.debug block. The debug keystore password and key password are hardcoded in the build.gradle file with values 'android'. While these are intended for development only, this is a security anti-pattern. Additionally, the debug.keystore file is committed to the repository, which should never contain production signing keys. Fix: 1. Move keystore credentials to gradle.properties or local.properties file (gitignored). 2. Never commit private keystores to version control. 3. Use environment variables or secure credential management for CI/CD pipelines. 4. Ensure debug.keystore is added to .gitignore.
• High · Debug Keystore Committed to Repository — app/debug.keystore. The debug.keystore file is present in the app directory and committed to the repository. If this were ever upgraded to a production keystore, it would expose the application's signing key. Fix: 1. Add *.keystore to .gitignore immediately. 2. Remove the file from git history using git filter-branch or BFG Repo-Cleaner. 3. Regenerate keystores if this repository is public. 4. Use a separate, non-committed keystore for release builds.
• Medium · Release Build Signed with Debug Keystore — app/build.gradle - buildTypes.release.signingConfig. The release buildType uses the debug signing configuration, which is inappropriate for production builds. This means production APKs would be signed with debug credentials, defeating the purpose of proper code signing. Fix: Create a separate signingConfigs block for release builds. Store release keystore credentials securely in an external configuration file (not in version control) and load them conditionally based on build type.
• Medium · Incomplete Dependency Declaration — app/build.gradle - final line of dependencies block. The build.gradle file has an incomplete line 'implementatio' at the end of the dependencies block, which appears to be a typo or cut-off. This could cause build failures or unexpected behavior. Fix: Complete or remove the incomplete dependency declaration. Review the build.gradle file for syntax errors and ensure all dependencies are properly declared.
• Medium · Disabled Lint Error Checking — app/build.gradle - lintOptions block. The lintOptions block sets 'abortOnError false', which disables lint error checking. This allows potentially problematic code patterns and security issues to be ignored during the build process. Fix: Enable lint error checking (abortOnError true) or configure specific lint checks to be warnings rather than errors. Address lint warnings during development to catch potential issues early.
• Low · Outdated or Potentially Vulnerable Dependencies — app/build.gradle - dependencies block. While the provided dependencies appear to be relatively recent, LeakCanary 2.10 and other libraries should be regularly updated. The lack of a complete dependency list makes it difficult to perform a comprehensive vulnerability assessment. Fix: 1. Run './gradlew dependencyUpdates' to check for outdated dependencies. 2. Use tools like Snyk or OWASP Dependency-Check to scan for known vulnerabilities. 3. Regularly update dependencies to their latest stable versions. 4. Monitor security advisories for all dependencies.
• Low · Test Instrumentation Runner Using Deprecated Library — app/build.gradle - defaultConfig.testInstrumentationRunner. The testInstrumentationRunner is set to 'android.support.test.runner.AndroidJUnitRunner', which uses the legacy Android Support Library instead of AndroidX. Fix: Migrate to AndroidX by using 'androidx.test.runner.AndroidJUnitRunner'. The Android Support Library is deprecated and no longer receives updates.

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.