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/Nightonke/BoomMenu 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.

AVOID — Stale and unlicensed — last commit 3y ago

• 3 active contributors
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 91% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ 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 Nightonke/BoomMenu repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Nightonke/BoomMenu.

What it runs against: a local clone of Nightonke/BoomMenu — 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 Nightonke/BoomMenu | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 1183 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Nightonke/BoomMenu(\\.git)?\\b" \\
  && ok "origin remote is Nightonke/BoomMenu" \\
  || miss "origin remote is not Nightonke/BoomMenu (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "boommenu/src/main/java/com/nightonke/boommenu/BoomMenuButton.java" \\
  && ok "boommenu/src/main/java/com/nightonke/boommenu/BoomMenuButton.java" \\
  || miss "missing critical file: boommenu/src/main/java/com/nightonke/boommenu/BoomMenuButton.java"
test -f "boommenu/src/main/java/com/nightonke/boommenu/BoomButton.java" \\
  && ok "boommenu/src/main/java/com/nightonke/boommenu/BoomButton.java" \\
  || miss "missing critical file: boommenu/src/main/java/com/nightonke/boommenu/BoomButton.java"
test -f "boommenu/src/main/java/com/nightonke/boommenu/Piece.java" \\
  && ok "boommenu/src/main/java/com/nightonke/boommenu/Piece.java" \\
  || miss "missing critical file: boommenu/src/main/java/com/nightonke/boommenu/Piece.java"
test -f "boommenu/src/main/java/com/nightonke/boommenu/BoomEnum.java" \\
  && ok "boommenu/src/main/java/com/nightonke/boommenu/BoomEnum.java" \\
  || miss "missing critical file: boommenu/src/main/java/com/nightonke/boommenu/BoomEnum.java"
test -f "build.gradle" \\
  && ok "build.gradle" \\
  || miss "missing critical file: build.gradle"

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

BoomMenu is an Android library that creates an expandable circular menu button with customizable child buttons that animate outward in various trajectories (line, parabola, horizontal throw). It solves the problem of fitting rich navigation options into compact mobile UIs through visually engaging, space-efficient menu expansion patterns. The core capability is the BoomMenuButton component (BMB) which can contain SimpleCircleButtons, TextInsideCircleButtons, or HamButtons with configurable placement, alignment, and animation styles. Single-module Android library (boommenu/) published to Bintray Maven Central. Core structure: src/main/java contains the animation engine and custom View subclasses (BoomMenuButton, BoomButton variants), src/main/res holds drawable and layout resources. Companion sample app (sample app module implied by buildTypes and applicationId 'com.nightonke.boommenusample') demonstrates usage patterns. Documentation lives in wiki and Pictures/ folder contains reference imagery for button types and animation trajectories.

Android developers building Android apps (API 14+) who need a visually engaging alternative to traditional dropdown menus, overflow menus, or FAB buttons. Particularly relevant for developers using ActionBar, ListView, or RecyclerView contexts who want to provide multiple actions without consuming screen real estate. Contributors are likely UI-focused Android engineers interested in animation, gesture handling, and custom view design.

Moderately mature and stable. The project reached version 2.1.1 after a significant 2.0.0 rewrite ~8 months post-inception, indicating deliberate evolution and design refinement. The presence of 21 versioned APKs in the Apk/ folder suggests active release cadence and testing. However, repo metadata (commit recency, test suite size, CI setup) is not visible in the provided file list, and the project appears to be primarily single-author maintained (Nightonke). Suitable for production use in most contexts, but maintainability depends on Nightonke's continued involvement.

Low-to-moderate risk. The library has minimal external dependencies (only Android Support Libraries v26.0.2, constraint-layout, and design library visible in build.gradle), reducing supply-chain risk. Single-maintainer risk is present given the author-centric GitHub presence. The codebase is pure Java/Android (393,427 lines) with no build automation visible (no Travis CI, GitHub Actions, or similar), so breaking changes or regressions may not be caught by CI. The 2.0.0 rewrite suggests the author is willing to introduce breaking changes for design improvements.

The codebase appears to be in maintenance mode. The latest versioned APK is V2.1.1 and build config shows versionName '2.1.1' with versionCode 2110. No active PR list, open issues, or recent commit data is visible in the provided snapshot. The author's note mentions completing the 2.0.0 redesign, suggesting the library reached its intended feature completeness. New activity would likely involve bug fixes, support for newer Android APIs, or dependency updates rather than major feature work.

Clone the repository: git clone https://github.com/Nightonke/BoomMenu.git && cd BoomMenu. Install dependencies and build the library module: ./gradlew :boommenu:build (or ./gradlew :boommenu:assembleRelease to build the library AAR for Maven publishing). Run the sample app: ./gradlew :sample:installDebug (or open in Android Studio and run the sample configuration). The Gradle wrapper is the build system; no npm, pip, or Maven CLI required.

Daily commands: After cloning: (1) Import into Android Studio or use ./gradlew tasks to list available tasks. (2) Build the library: ./gradlew :boommenu:build. (3) Install and run sample app on emulator or device: ./gradlew :sample:installDebug && adb shell am start -n com.nightonke.boommenusample/.MainActivity (or click Run in Android Studio). The app will launch the demo activity showing all button types (SimpleCircleButton, TextInsideCircleButton, HamButton, TextOutsideCircleButton) with interactive examples.

• boommenu/src/main/java/com/nightonke/boommenu/BoomMenuButton.java — Core menu component—entry point for all boom menu interactions and animations; every contributor must understand its lifecycle and state management
• boommenu/src/main/java/com/nightonke/boommenu/BoomButton.java — Abstract base class for all button types (HamButton, SimpleCircleButton, etc.); defines the contract for button behavior and rendering
• boommenu/src/main/java/com/nightonke/boommenu/Piece.java — Model class for individual menu items; critical data structure passed through animation and layout layers
• boommenu/src/main/java/com/nightonke/boommenu/BoomEnum.java — Enumeration defining all animation trajectories (parabola, horizontal-throw, line); governs movement math throughout the framework
• build.gradle — Project-level build configuration; specifies SDK versions (26), support libraries, and compilation targets that affect all modules
• boommenu/build.gradle — Library module configuration; defines the public API surface and dependencies exposed to consumers

• BoomMenuButton — undefined

Add a Custom Button Type

1. Extend BoomButton abstract class in boommenu/src/main/java/com/nightonke/boommenu/button/ (boommenu/src/main/java/com/nightonke/boommenu/BoomButton.java)
2. Override onDraw(Canvas) to render custom shape and onTouchEvent(MotionEvent) for interaction (boommenu/src/main/java/com/nightonke/boommenu/button/SimpleCircleButton.java)
3. Register button type in sample app and pass instance via Piece constructor (sample/src/main/java/com/nightonke/boommenu/sample/MainActivity.java)

Add a New Animation Trajectory

1. Add new enum constant to BoomEnum (e.g., SPIRAL, WAVE) with velocity/gravity parameters (boommenu/src/main/java/com/nightonke/boommenu/BoomEnum.java)
2. Implement trajectory calculation method returning x,y coordinates given time t and starting position (boommenu/src/main/java/com/nightonke/boommenu/BoomMenuButton.java)
3. Test animation in MainActivity by setting boom enum on BoomMenuButton instance (sample/src/main/java/com/nightonke/boommenu/sample/MainActivity.java)

Customize Menu Layout & Positioning

1. Choose ButtonPlaceEnum (BOTTOM, TOP, LEFT, RIGHT, custom coordinates) in activity (boommenu/src/main/java/com/nightonke/boommenu/ButtonPlaceEnum.java)
2. Set ButtonPlaceAlignmentEnum for button distribution (LEFT, CENTER, RIGHT or similar) (boommenu/src/main/java/com/nightonke/boommenu/ButtonPlaceAlignmentEnum.java)
3. Call setButtonPlaceEnum() and setButtonPlaceAlignmentEnum() on BoomMenuButton instance (boommenu/src/main/java/com/nightonke/boommenu/BoomMenuButton.java)

Add Menu Items and Bind Click Handlers

1. Create Piece objects for each menu item with button type, text, icon, and OnBoomButtonClickListener (boommenu/src/main/java/com/nightonke/boommenu/Piece.java)
2. Assemble List<Piece> and pass to BoomMenuButton.addBuilder() in MainActivity (sample/src/main/java/com/nightonke/boommenu/sample/MainActivity.java)
3. Implement listener callbacks and start menu animation with .boom() or .collapse() (boommenu/src/main/java/com/nightonke/boommenu/BoomMenuButton.java)

• Android Support Library v26 (AppCompat, Design, RecyclerView) — Provides backward compatibility down to API 14 and modern Material Design components for button styling
• Custom Canvas-based rendering (View onDraw) — Enables pixel-perfect control over button animations and trajectories without heavyweight GL overhead
• Enum-based configuration (BoomEnum, ButtonPlaceEnum, ButtonPlaceAlignmentEnum) — Provides type-safe, compile-time checked menu behavior variants reducing runtime errors
• Property Animation (ValueAnimator implied) — Smooth trajectory interpolation and frame-based animation updates at 60 FPS

• Canvas drawing over XML layouts for button rendering

  • Why: Fine-grained control over animation and transformation without layout inflation overhead
  • Consequence: Requires custom paint logic; harder to style buttons declaratively; accessibility features (a11y) must be manually implemented

• Enum configuration over fluent builder pattern

  • Why: Type safety and reduced configuration complexity
  • Consequence: Less flexibility for runtime property changes; users must recreate menu for different behaviors

• Synchronous trajectory math vs. physics engine

  • Why: Simpler implementation, lower CPU overhead, predictable performance
  • Consequence: Limited realism in gravity/collision; cannot adapt to real-time device motion sensors

• Real-time physics simulation or collision detection
• Accessibility (TalkBack) support for animated buttons
• Theming or dark mode integration
• Kotlin support or modern AndroidX migration
• Nested/hierarchical menu structures

No visible test suite: The file list contains no test/ or androidTest/ directories, so any changes risk regression. Bintray dependency: Library publishes to Bintray Maven (as seen in README), but Bintray shut down in 2021; users should verify migration to JCenter or Maven Central. Support library lock-in: build.gradle pins Android Support Library v26.0.2 (released ~2017); newer projects may conflict with AndroidX migrations. No ProGuard rules visible: The boommenu library should include consumer ProGuard rules (proguard-rules.pro) to ensure obfuscation doesn't break reflection or View instantiation; verify this file exists. API 14 minimum: Very old minimum SDK; ensure any new code doesn't accidentally use newer APIs (e.g., API 21+ padding/margin helpers). Animation frame rate: Canvas-based animation performance is not documented; performance on low-end devices (API 14–16) may be problematic but not tested in visible CI.

• Custom ViewGroup Layout & Measurement Pass — BoomMenuButton must override onMeasure() and onLayout() to position child buttons in a circular arc or grid; understanding the Android layout pass is essential to modifying button positioning
• Property Animation (ValueAnimator/ObjectAnimator) — The boom-out and collapse animations use Android's Property Animation framework to interpolate button positions over time; modifying animation speed, easing, or trajectory requires manipulating Animator objects
• Parametric Animation Curves (Parabola, Linear Throw) — BoomMenu implements multiple trajectory types (visible in Pictures/boom-enum/) that follow parametric equations; understanding parametric motion is key to adding new trajectory types or debugging button placement
• Canvas Drawing & Custom Paint — Button rendering (circles, text, ham-menu lines) uses Canvas.drawCircle(), drawText(), and Paint objects; customizing button appearance requires modifying drawing code
• Touch Event Dispatch & Hit Testing — Expanded buttons must respond to touches correctly; BoomMenuButton must override onTouchEvent() and perform hit detection on animated child button positions to route clicks correctly
• Android Support Library & API Compatibility Layers — The library targets API 14–26 using support-v7, design, and support-v4 libraries; understanding the compatibility shims (e.g., ViewCompat, AnimatorCompat) is necessary for safe API 14 support
• Easing Functions (Interpolators) — Button animations use AccelerateInterpolator, LinearInterpolator, or custom easing to create the 'boom' effect; choosing the right interpolator shapes the feel of the menu expansion

• Nightonke/VHBoomMenuButton — The iOS predecessor of BoomMenu that inspired the 2.0.0 Android redesign; shares button alignment and text-inside/outside design patterns
• rey5137/material-ripple — Complementary Material Design custom view library; same target audience (Android developers building polished custom UIs) with similar animation-heavy approach
• facebook/rebound — Physics-based animation library by Facebook; useful for developers wanting spring-based trajectories instead of BoomMenu's predefined Parabola/Line animations
• android/architecture-samples — Google's reference architecture repo; relevant for understanding modern Android project structure and dependency management practices that BoomMenu's build config pre-dates
• chrisbanes/PhotoView — Similar ecosystem role as BoomMenu: a single-purpose, well-designed Android custom View library that solves a specific UI problem elegantly

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 .gitignore entries for APK artifacts and build outputs

The Apk/ directory contains 21 compiled APK files (V1.0.1 through V2.1.1) that should not be version controlled. These are generated artifacts that bloat the repository, increase clone times, and violate best practices. Add proper .gitignore rules to exclude these while preserving the ability to document APK releases elsewhere (via GitHub Releases).

• [ ] Add '*.apk' to .gitignore to exclude all APK files
• [ ] Add 'Apk/' directory or '*.apk' patterns to .gitignore
• [ ] Add Android build outputs: 'build/', '.gradle/', '*.iml'
• [ ] Document in CONTRIBUTING.md that APK releases should use GitHub Releases instead
• [ ] Remove committed APK files via 'git rm --cached' (in separate cleanup PR)

Create unit tests for BoomMenu animation and button placement logic

The Pictures directory shows extensive button placement enumerations (6+ placement positions per button type) and animation types (horizontal-throw, parabola, line). These configurations are core features but there's no evidence of unit tests validating that animations and placements work correctly. Add instrumented tests for the boommenu module to verify button positioning and animation sequences.

• [ ] Create androidTest/java/com/nightonke/boommenu/ directory structure
• [ ] Add tests for BoomButton placement calculations against BoomPlace enum values
• [ ] Add animation tests verifying parabola, line, and horizontal-throw trajectories complete
• [ ] Add tests for ButtonPlaceAlignment enum logic (left, center, right alignments)
• [ ] Document test setup in CONTRIBUTING.md with instrumentation test instructions

Add GitHub Actions CI workflow for automated APK builds and testing

With 21 historical APK versions and compileSdkVersion 26, the project needs automated CI to catch regressions. The repo lacks any CI configuration, making it difficult for contributors to validate changes before submitting PRs. Add a GitHub Actions workflow that builds the app, runs unit/instrumented tests, and generates APK artifacts.

• [ ] Create .github/workflows/android-build.yml workflow file
• [ ] Configure workflow to trigger on push to main and PR branches
• [ ] Add steps for: Gradle setup, compile boommenu module, run unit tests, run instrumented tests (if emulator available)
• [ ] Archive generated APK as workflow artifact instead of committing to repo
• [ ] Add status badge to README.md linking to Actions page

• Add unit tests for BoomMenuButton expand/collapse state transitions: The library has no visible test directory. Create androidTest/java/com/nightonke/boommenu/BoomMenuButtonTest.java to test: (1) initial state is collapsed, (2) calling boom() transitions to expanded with correct child button positions, (3) calling boom() again collapses, (4) multiple rapid boom() calls don't corrupt state. This catches regressions in animation timing and state management.
• Document button placement enums with code examples in README: The Pictures/button-place-enum/ folder contains 11 reference images (ham-button 1–6, simple-circle-button 2–3 variants, horizontal/vertical) showing different placement modes, but the README.md does not explain which enum values produce which layouts. Add a section 'Button Placement Reference' with one code snippet and matching image for each placement option (e.g., Parabola-Left-Top, HorizontalThrow-Bottom, etc.) to make the library more discoverable.
• Upgrade Android Support Library to AndroidX and test migration: build.gradle still uses android.support:* v26.0.2 from 2017. Create a branch that updates to androidx:* equivalents (androidx.appcompat:appcompat:1.x, androidx.design:material:1.x, etc.), run the sample app on API 26+ and API 21 devices to verify no visual/functional regression, then document the breaking change in CHANGELOG.md. This unblocks developers using modern Android Studio templates.

The BoomMenu project has significant security concerns primarily related to outdated dependencies and build configurations. The use of Android SDK 26, legacy Support Libraries, and disabled code obfuscation creates an environment vulnerable to known exploits and makes reverse engineering straightforward. The inclusion of compiled APK files in version control is a maintenance and integrity concern. Immediate action is required to update the build system to current standards, enable minification, migrate to AndroidX, and remove binary artifacts from version control. These changes are critical for both user security and compliance with modern app store requirements.

• High · Outdated Android SDK and Build Tools — build.gradle (defaultConfig and android sections). The project uses compileSdkVersion 26 (Android 8.0) and buildToolsVersion 25.0.2, which are significantly outdated. This exposes the application to known security vulnerabilities that have been patched in newer Android versions. Modern best practices recommend using the latest stable SDK version. Fix: Update compileSdkVersion to 34 or higher, and buildToolsVersion to the latest stable version (e.g., 34.0.0). This ensures access to the latest security patches and modern API protections.
• High · Outdated Support Library Dependencies — build.gradle (dependencies section). The project uses Android Support Library version 26.0.2, which is outdated and no longer receives security updates. AndroidX (the modern replacement) includes critical security improvements and bug fixes that are not available in legacy support libraries. Fix: Migrate from Android Support Libraries to AndroidX. Update dependencies to use androidx.appcompat:appcompat:1.x.x and equivalent androidx versions. This provides ongoing security maintenance and modern API features.
• Medium · Low Target SDK Version — build.gradle (targetSdkVersion). The targetSdkVersion is set to 26 (Android 8.0). Google Play Store requires a minimum targetSdkVersion that is close to the latest released Android version. Using an old target SDK means the app does not benefit from runtime permission models, scoped storage, and other security features introduced in newer Android versions. Fix: Update targetSdkVersion to 34 or higher (current/latest stable Android version). Ensure the application is compatible with modern Android permission models and privacy features.
• Medium · ProGuard/R8 Minification Disabled in Release Build — build.gradle (buildTypes.release). The release build configuration has minifyEnabled set to false. This means the application code is not obfuscated before release, making reverse engineering easier and potentially exposing sensitive logic, API keys, or hardcoded credentials embedded in the source code. Fix: Enable minification by setting minifyEnabled to true and ensure proper ProGuard/R8 configuration rules are in place to protect sensitive code and APIs while maintaining functionality.
• Medium · Compiled APK Files in Version Control — /Apk directory containing 21 APK files. The repository contains multiple compiled APK files (BoomMenu V1.0.1 through V2.1.1) in the /Apk directory. Storing compiled binaries in version control increases repository size, complicates history, and makes it difficult to verify the integrity and provenance of releases. Fix: Remove APK files from the repository and use a dedicated artifact management system (Maven Central, Bintray, GitHub Releases). Update .gitignore to exclude *.apk files and build artifacts. This improves security visibility and repository maintainability.
• Low · Insufficient Minimum SDK Version — build.gradle (minSdkVersion). minSdkVersion is set to 14 (Android 4.0), which is extremely outdated and no longer receives security updates. Supporting such old versions increases the attack surface as these versions lack modern security features and protections. Fix: Increase minSdkVersion to at least 24 (Android 7.0) or higher, depending on target user base and market analysis. This allows the application to leverage modern security features and reduces support burden for legacy systems.

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.