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/umano/AndroidSlidingUpPanel 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 4y ago

• 17 active contributors
• Apache-2.0 licensed
• CI configured
• ⚠ Stale — last commit 4y ago
• ⚠ Concentrated ownership — top contributor handles 66% of recent commits
• ⚠ No test directory 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 umano/AndroidSlidingUpPanel repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/umano/AndroidSlidingUpPanel.

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "umano/AndroidSlidingUpPanel(\\.git)?\\b" \\
  && ok "origin remote is umano/AndroidSlidingUpPanel" \\
  || miss "origin remote is not umano/AndroidSlidingUpPanel (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master 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 1417 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1387d)"
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/umano/AndroidSlidingUpPanel"
  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).

AndroidSlidingUpPanel is a library that adds a draggable, animated sliding panel to Android applications, similar to the UI pattern used in Google Music and Google Maps. It provides the SlidingUpPanelLayout class (library/src/main/java/com/sothree/slidinguppanel/SlidingUpPanelLayout.java) as a ViewGroup that manages two child views: a main content area and a draggable panel that slides up from the bottom with configurable height, shadow effects, and drag regions. Two-module Gradle structure: library/src/main/java/com/sothree/slidinguppanel/ contains the core implementation (SlidingUpPanelLayout.java, ViewDragHelper.java, ScrollableViewHelper.java), while demo/ contains a working example app (demo/src/main/java/com/sothree/slidinguppanel/demo/DemoActivity.java and demo/src/main/res/layout/activity_demo.xml) demonstrating usage. XML resources for styling are in library/src/main/res/drawable/.

Android developers building mobile apps who need to implement the sliding panel UI pattern (as popularized by Google and adopted by Soundcloud, Dropbox Paper, and Snaptee) without building the layout management and gesture detection from scratch.

Production-ready but dormant: the library is stable (version 3.4.0, published to Maven Central), used in major apps, and has clear documentation. However, the maintainers explicitly state they are 'not actively responding to issues' and community PRs are the expected contribution path. No recent CI/commit activity is visible in the provided data.

Low technical risk for standard use cases, but uncertain long-term maintenance: the library has no active maintainers responding to issues, making it dependent on community PRs for bug fixes. The codebase is Java-only (~117KB) with minimal external dependencies (Gradle build), reducing supply-chain risk. Biggest risk is if breaking changes occur in Android Framework versions not yet handled by the library.

The repository appears inactive—no recent commit information is provided in the file list. The README notes maintainers are not actively responding and direct users to submit PRs for bugs. This suggests the library is in maintenance mode, accepting community contributions but not driving new feature development.

git clone https://github.com/umano/AndroidSlidingUpPanel.git
cd AndroidSlidingUpPanel
./gradlew build
./gradlew demo:build

Then open the demo/ folder in Android Studio or run ./gradlew demo:installDebug to deploy the demo app to an emulator/device.

Daily commands:

./gradlew demo:installDebug

This compiles and deploys the demo app. For development, import the project into Android Studio and run the demo module as an application configuration targeting an emulator or connected device.

• library/src/main/java/com/sothree/slidinguppanel/SlidingUpPanelLayout.java: Core layout class that manages the two-child hierarchy, drag state machine, animations, and attribute handling (umanoPanelHeight, umanoShadowHeight, umanoDragView)
• library/src/main/java/com/sothree/slidinguppanel/ViewDragHelper.java: Handles touch event interception, gesture velocity tracking, and smooth drag/settle animations using Android's ViewDragHelper pattern
• library/src/main/java/com/sothree/slidinguppanel/ScrollableViewHelper.java: Adapter for detecting and handling nested scrollable views (ListView, RecyclerView) so drags don't conflict with child scroll events
• demo/src/main/res/layout/activity_demo.xml: Concrete XML example showing correct SlidingUpPanelLayout usage with gravity, panel height, shadow, and two child layout pattern
• library/build.gradle: Defines library module configuration, Android API target, and Maven publication settings for Maven Central release

For core sliding behavior changes: edit library/src/main/java/com/sothree/slidinguppanel/SlidingUpPanelLayout.java. For gesture/drag logic: modify library/src/main/java/com/sothree/slidinguppanel/ViewDragHelper.java. For scrollable view support: update library/src/main/java/com/sothree/slidinguppanel/ScrollableViewHelper.java. For demo/testing: see demo/src/main/java/com/sothree/slidinguppanel/demo/DemoActivity.java and demo/src/main/res/layout/activity_demo.xml. XML attributes are defined implicitly in SlidingUpPanelLayout; no explicit attr resource file is listed.

1. The library requires exactly two direct children in SlidingUpPanelLayout (main content + panel); adding more or fewer children will cause layout bugs. 2) The android:gravity attribute must be set to 'top' or 'bottom' and is mandatory—omitting it is a silent failure. 3) Custom drag views must be explicitly set via setDragView() or the umanoDragView attribute; otherwise the entire panel is draggable and will consume all touch events. 4) Nested RecyclerView or ListView scrolling requires ScrollableViewHelper integration; without it, vertical scrolls will drag the panel instead. 5) Shadow height (umanoShadowHeight) uses a 9-patch drawable (library/src/main/res/drawable/above_shadow.xml) that must exist; missing it silently fails.

• ViewGroup Layout Measurement & Drawing Lifecycle — SlidingUpPanelLayout overrides onMeasure() and onLayout() to position two children correctly during drag; understanding View measure specs and layout bounds is essential to modify panel sizing or state propagation
• Android ViewDragHelper (GestureDetector-based touch event routing) — The library's drag detection is built on ViewDragHelper, which filters touch events, computes velocity, and manages the drag state machine; understanding this is key to modifying gesture behavior or fixing touch event conflicts
• Nested Scrolling Contract (NestedScrollingParent/Child) — ScrollableViewHelper uses the NestedScrolling APIs to detect RecyclerView/ListView scroll events and prevent them from triggering panel drag; critical for apps with scrollable content in the panel
• Scroller & ValueAnimator (smooth animation & settle behavior) — SlidingUpPanelLayout uses Scroller and/or ValueAnimator to interpolate panel position during drag settle and momentum scrolling; understanding easing functions affects the 'feel' of drag transitions
• 9-Patch Drawable (NinePatchDrawable) — The above_shadow.xml drawable is a 9-patch that scales the shadow correctly without distortion; important for understanding how drawable resources are structured and why bitmap stretching matters in UI
• Android Custom Attributes & TypedArray — SlidingUpPanelLayout defines custom XML attributes (umanoPanelHeight, umanoDragView, umanoShadowHeight) parsed via TypedArray in the constructor; knowing how to define and read custom attrs is essential for extending the library
• Invalidation & RequestLayout Patterns — Panel state changes require calling invalidate() (redraw) or requestLayout() (remeasure); misusing these patterns causes visual glitches or performance issues when updating panel height or state

• AndroidKnowledgeGraph/SlidingMenu — Alternative drawer/panel sliding implementation for Android; solves the same UI pattern problem but with different API and architecture
• chrisbanes/PhotoView — Companion library for pinch-zoom gestures in Android; often used together with sliding panels to handle image viewing in the panel area
• google/material-components-android — Modern Material Design library that includes BottomSheetDialogFragment and ModalBottomSheetDialog as native alternatives to custom sliding panels
• androidx/constraintlayout — Modern alternative layout engine that can achieve similar sliding panel effects without a custom ViewGroup via motion layouts
• umano/AndroidSlidingUpPanelDemo — Original demo repository showing real-world usage patterns and more complex examples than the bundled demo/ module

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 SlidingUpPanelLayout.java core functionality

The library's main component (library/src/main/java/com/sothree/slidinguppanel/SlidingUpPanelLayout.java) has no visible test suite. Given this is a high-usage layout component handling drag gestures, touch events, and panel state transitions, unit tests would catch regressions and validate behavior across different panel states (collapsed, expanded, anchored) and edge cases like rapid gestures or boundary conditions.

• [ ] Create library/src/test/java/com/sothree/slidinguppanel/ directory structure
• [ ] Add SlidingUpPanelLayoutTest.java with tests for: panel state transitions, drag gesture handling, and boundary conditions
• [ ] Add testImplementation dependencies (JUnit, Mockito, AndroidX test) to library/build.gradle
• [ ] Test anchor point behavior, expand/collapse callbacks, and scroll view compatibility with ScrollableViewHelper.java

Migrate from deprecated Gradle Android plugin to modern AndroidX and update build config

The build.gradle uses com.android.tools.build:gradle:2.3.2 (released 2017) and the build script is missing modern Android plugin conventions. The codebase lacks AndroidX migration, which is critical for compatibility with recent Android versions and Play Store requirements. This includes updating library/build.gradle to specify targetSdkVersion/compileSdkVersion and adding androidx dependencies.

• [ ] Update buildscript in build.gradle to use com.android.tools.build:gradle:7.x or 8.x LTS
• [ ] Add compileSdk 34 (or latest stable) and targetSdk 34 to library/build.gradle and demo/build.gradle
• [ ] Add androidx.appcompat:appcompat and androidx.core:core dependencies to library/build.gradle
• [ ] Update library/src/main/AndroidManifest.xml to include android:usesCleartextTraffic if needed for API 28+
• [ ] Test compatibility with minSdk (likely 16+) and validate ViewDragHelper.java works with modern framework

Add instrumentation tests for touch/drag interactions in DemoActivity

The demo app (demo/src/main/java/com/sothree/slidinguppanel/demo/DemoActivity.java) exists but there are no instrumentation tests validating the actual UI behavior—dragging, fling gestures, panel snapping, and interaction with the underlying scrollable content. This is especially important for a gesture-heavy library where touch handling bugs are common.

• [ ] Create demo/src/androidTest/java/com/sothree/slidinguppanel/demo/ directory
• [ ] Add DemoActivityTest.java using AndroidX test libraries (androidx.test.ext:junit, espresso)
• [ ] Write tests for: swipe-up to expand, swipe-down to collapse, drag to anchor point, and interaction with RecyclerView/ScrollView in the panel
• [ ] Add androidTestImplementation dependencies to demo/build.gradle
• [ ] Verify tests pass on minSdk target device/emulator to catch API compatibility issues

• Add unit tests for SlidingUpPanelLayout state transitions (collapsed → expanded → dragging) in library/src/test/ (currently no test directory exists in the file list). This improves maintainability and prevents regressions.
• Create a Kotlin extension file (library/src/main/kotlin/com/sothree/slidinguppanel/SlidingUpPanelExt.kt) with convenience builders and listener DSLs for modern Android development, since the library is Java-only and many apps now use Kotlin.
• Document the ViewDragHelper gesture velocity and settle behavior in JavaDoc comments and add a demo activity example showing rapid swipe-to-expand/collapse (demo/src/main/java/com/sothree/slidinguppanel/demo/ currently has only DemoActivity.java). This closes the gap between API capability and user knowledge.

This Android library has significant security concerns, primarily centered around outdated build tools and deprecated dependency repositories. The Gradle 2.3.2 and jcenter() repository configuration are from 2016 and no longer receive security updates. The lack of explicit dependency versioning and absence of security scanning in the CI/CD pipeline create additional risks. While the codebase itself (UI library) has limited injection attack surface, the build infrastructure requires modernization. Immediate action is needed to update Gradle, switch to secure repositories, and implement dependency vulnerability scanning.

• High · Outdated Gradle Build Tools — build.gradle. The project uses Gradle 2.3.2 (from 2016) which is significantly outdated and contains known security vulnerabilities. This version lacks security patches and modern dependency management features. Fix: Update to the latest stable Gradle version (7.x or 8.x). Update Android Gradle plugin to 7.x or later.
• High · Insecure Repository Configuration — build.gradle (allprojects section). The build configuration uses HTTP and jcenter() repository which is deprecated and no longer maintained. jcenter() was shut down by JFrog and no longer receives updates or security patches. Fix: Replace jcenter() with mavenCentral(). Ensure all repository URLs use HTTPS. Update to use Google's Maven repository and Maven Central exclusively.
• Medium · Missing Dependency Version Management — build.gradle, library/build.gradle, demo/build.gradle. The project does not specify explicit versions for dependencies in the build.gradle, relying on dynamic version resolution. This can lead to unpredictable builds and potential inclusion of vulnerable dependencies. Fix: Explicitly pin all dependency versions. Implement a dependency management strategy using a BOM (Bill of Materials) or version catalog. Use './gradlew dependencyUpdates' to identify outdated dependencies.
• Medium · No Security Scanning in Build Pipeline — .travis.yml. The .travis.yml configuration does not include security scanning tools (e.g., OWASP Dependency Check, Gradle Security) to detect vulnerable dependencies during CI/CD. Fix: Integrate security scanning tools into the build pipeline. Consider using Gradle plugin for dependency vulnerabilities, OWASP Dependency-Check, or similar tools.
• Medium · Gradle Wrapper Security — gradle/wrapper/gradle-wrapper.jar. The Gradle wrapper JAR file (gradle/wrapper/gradle-wrapper.jar) is a binary committed to the repository. If compromised, it could execute arbitrary code during builds. Fix: Consider using './gradlew wrapper --gradle-version=<version>' to regenerate the wrapper. Verify the checksum of wrapper files. Consider documenting the expected hash of wrapper JARs for verification.
• Low · No ProGuard/R8 Configuration — library/build.gradle. The library lacks ProGuard/R8 configuration files for code obfuscation and shrinking, which could make the compiled code easier to reverse engineer. Fix: Configure ProGuard or R8 rules in a proguard-rules.pro file. Set minifyEnabled to true for release builds.
• Low · Missing Security-Related Gradle Properties — gradle.properties. No gradle.properties configuration for security-related settings such as org.gradle.jvmargs for memory limits or security flags. Fix: Configure gradle.properties with security-aware settings. Consider adding org.gradle.jvmargs with memory and security parameters.

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.