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/huanghaibin-dev/CalendarView 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.

GO — Healthy across all four use cases

• Last commit 5mo ago
• 6 active contributors
• Apache-2.0 licensed
• Tests present
• ⚠ Slowing — last commit 5mo ago
• ⚠ Single-maintainer risk — top contributor 86% 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 huanghaibin-dev/CalendarView repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/huanghaibin-dev/CalendarView.

What it runs against: a local clone of huanghaibin-dev/CalendarView — 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 huanghaibin-dev/CalendarView | 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 ≤ 185 days ago | Catches sudden abandonment since generation |

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

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

CalendarView is an ultra-high-performance Android calendar widget built entirely on Canvas rendering instead of RecyclerView/ListView, enabling pixel-perfect customization with minimal memory footprint. It supports month view, week view, year view, vertical/horizontal layout switching, and custom animations while maintaining 60fps rendering through direct canvas drawing. Single-module library structure: calendarview/ directory contains core Canvas-based rendering (MonthView.java, WeekView.java, YearView.java, WeekBar.java mentioned in proguard rules). The app/ folder contains a full demo application showcasing usage patterns. No monorepo or complex layering—straightforward library + demo layout.

Android developers building apps requiring calendar UI (scheduling apps, date pickers, event management) who need iOS-like polish, full customization control, and cannot tolerate the memory/performance overhead of RecyclerView-based calendar implementations.

Production-ready and stable: last open-source release was 3.7.1 (Androidx version). The project has substantial real-world usage (demonstrable via the demo APK included in repo). However, active development has ceased for the open-source version—further features (vertical/horizontal switching, custom animations) were moved to closed-source commercial versions. Test coverage appears minimal based on file structure.

Single-maintainer risk is high (huanghaibin-dev only visible contributor). Project pivoted to commercial model post-3.7.1, meaning critical bugs in open-source version may not receive patches. No visible CI/CD pipeline (no .github/workflows), no automated tests in file list, and no recent commit timestamps available—dormancy risk for the open-source branch is significant.

The open-source codebase is in maintenance mode. README explicitly states that versions after 3.7.1 with vertical/horizontal switching and custom animations are closed-source. No active issues, PRs, or milestones are visible in the provided data. The last meaningful work occurred during the 3.x release cycle.

git clone https://github.com/huanghaibin-dev/CalendarView.git
cd CalendarView
./gradlew assembleDebug
./gradlew installDebug

Or import the project into Android Studio 3.5+ and run the app module directly. Gradle will fetch androidx dependencies automatically.

Daily commands:

./gradlew assembleDebug
./gradlew installDebug -Pandroid.testInstrumentationRunner=androidx.test.runner.AndroidJUnitRunner
adb shell am start -n com.haibin.calendarviewproject/.MainActivity

Or open in Android Studio, connect a device/emulator, and press Run (Shift+F10). No web server or external services required.

• calendarview/src/main/java/com/haibin/calendarview/MonthView.java: Core canvas rendering for month calendar display—primary performance-critical component
• calendarview/src/main/java/com/haibin/calendarview/WeekView.java: Week view canvas renderer, used for compact calendar display mode
• calendarview/src/main/java/com/haibin/calendarview/YearView.java: Year overview calendar implementation with nested month rendering
• calendarview/src/main/java/com/haibin/calendarview/Calendar.java: Custom Calendar model class—stores date, lunar calendar, holidays, and event metadata
• app/src/main/java/com/haibin/calendarviewproject/MainActivity.java: Demo application entry point showing all major calendar use cases and customization examples
• app/build.gradle: Demo app build config including dependency on local calendarview module via implementation project(':calendarview')
• app/proguard-rules.pro: Critical for release builds—must preserve View constructors used by inflation

For UI customization: examine app/src/main/res/layout/ and app/src/main/java/com/haibin/calendarviewproject/ for integration patterns. To modify core rendering: edit the View subclasses (MonthView, WeekView, YearView) in calendarview/ module—these contain onDraw() methods where Canvas commands execute. For date logic: search for Calendar.getInstance() usage in core classes. ProGuard rules must be updated if refactoring class names (see proguard-rules.pro).

1. Proguard configuration is essential: if you enable minification without the rules in proguard-rules.pro, custom View constructors will be stripped and inflation will crash. 2) The library uses direct View subclassing (MonthView, WeekView, YearView), not ViewGroup composition—nested calendar hierarchies don't work. 3) Canvas rendering is tied to single-threaded UI thread; long-running date calculations on UI thread will cause jank. 4) The README warns that open-source is frozen at 3.7.1—newer versions with advanced features require purchasing the commercial version. 5) No Jetpack Compose support; this is View-based only.

• Canvas rendering & onDraw() lifecycle — CalendarView's entire performance advantage comes from bypassing RecyclerView and drawing directly to Canvas in onDraw()—understanding Android's drawing pipeline (requestLayout → measure → layout → draw) is mandatory
• Custom View measurement & layout (MeasureSpec) — MonthView, WeekView, YearView must implement onMeasure() and onLayout() correctly to size themselves and children—improper measurement causes layout corruption
• Lunar calendar conversion algorithm — CalendarView supports Chinese lunar dates (农历)—the conversion between solar (Gregorian) and lunar calendars uses a lookup table + calculation, visible in Calendar.java
• Touch event dispatch & gesture handling — Calendar must handle month/week navigation via swipes and date selection via taps—implementing onTouchEvent() correctly for Canvas-based views differs from RecyclerView's built-in handling
• View state persistence (onSaveInstanceState) — Calendar must save selected date and current month across configuration changes (rotation)—improper state management loses user's position
• Memory-efficient bitmap caching for date cells — Canvas rendering can avoid RecyclerView's view recycling overhead only if date cell layouts are cached efficiently—the library likely uses Paint object pooling and drawable state caching
• Locale-aware date formatting & text layout — CalendarView supports multiple languages (English, Chinese, etc.) with right-to-left (RTL) locale awareness—Canvas.drawText() requires explicit RTL handling and locale-specific calendars

• kizitonwose/Calendar — Jetpack Compose alternative for modern Android apps—similar feature set (month/week views, customizable) but for compose-first projects
• prolificinteractive/material-calendarview — RecyclerView-based calendar offering similar month/week views—shows the performance tradeoff this repo avoids via Canvas
• alamkanak/Android-Week-View — Specialized week/agenda view for event scheduling—complementary to CalendarView for time-slotted event displays
• huanghaibin-dev/CalendarView-commercial — Closed-source paid version with vertical/horizontal animation and advanced features—successor to this open-source project
• AndroidKnife/NoHttp — Common dependency in Chinese-developed Android libraries—shows ecosystem context for this repo's origin

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 CalendarView canvas rendering and performance metrics

The repo has an empty androidTest directory (app/src/androidTest/java/com/haibin/calendarviewproject/ExampleInstrumentedTest.java) with only a placeholder test. Given that the library emphasizes 'ultra performance' and 'extremely low memory' as core selling points, there should be instrumented tests measuring canvas rendering performance, memory allocation, and frame rate consistency. This validates the performance claims and prevents regressions.

• [ ] Create performance benchmark tests in app/src/androidTest/java/com/haibin/calendarviewproject/ measuring canvas draw() call duration
• [ ] Add memory profiling tests to verify low memory footprint during month/week view transitions
• [ ] Add frame rate validation tests to ensure smooth 60fps rendering across different calendar operations
• [ ] Document performance baseline expectations in a new PERFORMANCE_TESTING.md file

Add comprehensive unit tests for custom calendar logic in calendarview module

The repo references a ':calendarview' module (in app/build.gradle dependencies) but the actual calendarview library source is not shown in the file structure. Based on the description mentioning '自定义周起始' (custom week start) and support for vertical/horizontal modes, there are likely complex date calculation and view state management logics that lack unit test coverage. Adding tests would improve code reliability and make contributions safer.

• [ ] Create unit tests for week-start-day calculation logic (e.g., testing Sunday vs Monday as week start)
• [ ] Add tests for date range selection and validation logic
• [ ] Create tests for calendar grid layout calculations in both vertical and horizontal orientations
• [ ] Add tests to verify correct handling of edge cases (leap years, month boundaries, DST transitions)

Create a GitHub Actions CI workflow for automated testing and APK builds

The repo has a CalendarViewDemo.apk checked into git (anti-pattern for binary management) and no visible CI/CD pipeline. Adding a GitHub Actions workflow would automate test execution, verify builds succeed, catch regressions early, and provide reproducible APK artifacts without storing binaries in git. This improves maintainability and contribution quality.

• [ ] Create .github/workflows/android-ci.yml to run ./gradlew build and test tasks on PRs
• [ ] Configure the workflow to execute both unit tests and instrumented tests (androidTest)
• [ ] Add a step to upload test reports as artifacts for visibility into test failures
• [ ] Document the CI setup in a new CONTRIBUTING.md file explaining the build and test process

• Add unit tests for date calculation logic: calendarview/src/main/java/com/haibin/calendarview/Calendar.java lacks testable methods for lunar calendar conversion and holiday detection. Extracting pure functions and adding JUnit tests would prevent regressions.
• Implement instrumented tests for Canvas rendering accuracy: app/src/androidTest/ is empty. Add visual regression tests comparing onDraw() output for MonthView, WeekView, YearView against reference PNGs for different locales (especially CJK characters).
• Document custom view styling: README lacks code examples showing how to subclass MonthView and override getDrawPaint(), getPaint() to customize colors/fonts. Add a docs/CUSTOMIZATION.md with before/after code samples.

This Android calendar library project has significant security concerns primarily related to severely outdated dependencies and SDK versions. The codebase targets Android 9.0 (2018) with dependencies from 2017-2018, missing years of security patches. ProGuard obfuscation is disabled in release builds, making reverse engineering easier. The project uses Gradle suppressed warnings without clear justification and includes unrestricted JAR file dependencies. Immediate action is required to update all dependencies, target modern Android APIs (SDK 34+), enable code obfuscation, and establish a regular dependency update schedule. Without these changes, the application is exposed to multiple known vulnerabilities and lacks modern Android security features.

• High · Outdated Gradle Dependencies with Known Vulnerabilities — app/build.gradle - dependencies section. The project uses outdated dependencies including Glide 4.5.0 (released 2017) and Material 1.2.1 which contain known security vulnerabilities. These old versions may have unpatched security issues. Fix: Update to latest stable versions: Glide 4.15.1+, Material 1.9.0+, and AppCompat 1.6.1+
• High · Deprecated and Vulnerable Compile/Target SDK Versions — app/build.gradle - compileSdkVersion and targetSdkVersion. The project targets SDK version 28 (Android 9.0, released 2018) which is significantly outdated. This misses critical security patches and modern security features available in newer Android versions. Additionally, minSdkVersion 15 is extremely outdated and unsupported. Fix: Update compileSdkVersion and targetSdkVersion to at least 34 (Android 14). Update minSdkVersion to at least 24 (Android 7.0) for better security baseline.
• Medium · ProGuard Obfuscation Disabled in Release Build — app/build.gradle - buildTypes.release. The release build has minifyEnabled set to false, meaning code is not obfuscated. This makes it easier for attackers to reverse engineer the application and discover vulnerabilities or extract sensitive logic. Fix: Set minifyEnabled to true and enable code shrinking: 'minifyEnabled true' with appropriate ProGuard rules in proguard-rules.pro
• Medium · Deprecated Testing Framework — app/build.gradle - androidTestImplementation. The project uses androidx.test.espresso:espresso-core:3.1.0 (released 2018) which is outdated. Current versions include critical bug fixes and security improvements. Fix: Update to androidx.test.espresso:espresso-core:3.5.1 or latest stable version
• Medium · Unrestricted File Tree Dependency — app/build.gradle - dependencies section. The build configuration includes 'fileTree(include: ['*.jar'], dir: 'libs')' which automatically includes all JAR files from the libs directory without explicit version control or verification. This could lead to accidental inclusion of vulnerable or malicious JAR files. Fix: Replace with explicit dependency declarations specifying exact versions. If JAR files must be used, implement strict version management and security scanning.
• Low · Missing Security Annotations and Comments — app/build.gradle - multiple lines with //noinspection. The codebase contains suppressed Gradle warnings (//noinspection comments) for compatibility and deprecated API usage without documented security justification. Fix: Document the reasons for these suppressions and plan migration paths to supported APIs and configurations
• Low · Binary APK in Version Control — CalendarViewDemo.apk. The compiled APK file (CalendarViewDemo.apk) is stored in the Git repository, which is inefficient and could contain sensitive debugging information. Fix: Add *.apk to .gitignore and use CI/CD pipeline or release artifacts for APK distribution instead

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.