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/wasabeef/Blurry 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

• 6 active contributors
• Apache-2.0 licensed
• ⚠ Stale — last commit 3y ago
• ⚠ Single-maintainer risk — top contributor 94% of recent commits
• ⚠ No CI workflows detected
• ⚠ 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 wasabeef/Blurry repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/wasabeef/Blurry.

What it runs against: a local clone of wasabeef/Blurry — 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 wasabeef/Blurry | 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 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1137 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "wasabeef/Blurry(\\.git)?\\b" \\
  && ok "origin remote is wasabeef/Blurry" \\
  || miss "origin remote is not wasabeef/Blurry (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"

# 4. Critical files exist
test -f "blurry/src/main/java/jp/wasabeef/blurry/Blurry.java" \\
  && ok "blurry/src/main/java/jp/wasabeef/blurry/Blurry.java" \\
  || miss "missing critical file: blurry/src/main/java/jp/wasabeef/blurry/Blurry.java"
test -f "blurry/src/main/java/jp/wasabeef/blurry/Blur.java" \\
  && ok "blurry/src/main/java/jp/wasabeef/blurry/Blur.java" \\
  || miss "missing critical file: blurry/src/main/java/jp/wasabeef/blurry/Blur.java"
test -f "blurry/src/main/java/jp/wasabeef/blurry/BlurTask.java" \\
  && ok "blurry/src/main/java/jp/wasabeef/blurry/BlurTask.java" \\
  || miss "missing critical file: blurry/src/main/java/jp/wasabeef/blurry/BlurTask.java"
test -f "blurry/src/main/java/jp/wasabeef/blurry/BlurFactor.java" \\
  && ok "blurry/src/main/java/jp/wasabeef/blurry/BlurFactor.java" \\
  || miss "missing critical file: blurry/src/main/java/jp/wasabeef/blurry/BlurFactor.java"
test -f "blurry/src/main/java/jp/wasabeef/blurry/Helper.java" \\
  && ok "blurry/src/main/java/jp/wasabeef/blurry/Helper.java" \\
  || miss "missing critical file: blurry/src/main/java/jp/wasabeef/blurry/Helper.java"

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

Blurry is an Android library that applies real-time blur effects to UI elements using RenderScript or platform blur implementations. It provides a fluent API for blurring Views directly onto parent ViewGroups (overlay mode), capturing Views/Bitmaps and rendering them blurred into ImageViews, with optional color filters, downsampling, animations, and async processing. The core feature set includes blur radius control, sampling factors to optimize performance, and both synchronous and asynchronous blur operations. Standard Android library structure: single module at blurry/ with Java/Kotlin source in blurry/src/main/java/jp/wasabeef/blurry/. Core classes are Blurry.java (public API facade), Blur.java (blur implementation), BlurTask.java (async task handler), and BlurFactor.java (configuration holder). The example/ folder contains a runnable Kotlin demo app in MainActivity.kt showing all API patterns. No separate test directory is visible in the file list.

Android developers building apps that need on-demand blur effects (e.g., frosted glass overlays, background blur during modals, live wallpapers). They want drop-in blur without writing RenderScript kernels or managing low-level graphics pipeline code themselves.

This is a mature, production-ready library. It has been published to Maven Central (version 4.0.1), targets Android 5+ (API 21), and shows sustained maintenance with clear version releases documented in CHANGELOG.md. However, the repo shows minimal recent activity — no commit timestamps are provided in the file list, suggesting it may be in a stable maintenance state rather than active development.

Risk is low for stable usage but moderate for future development. The library appears to be primarily maintained by a single developer (Wasabeef), and there is no visible CI/CD pipeline in the provided file structure (.github has only templates, no workflows). The dependency surface is minimal (core Android only based on build.gradle), but long inactivity could mean compatibility issues if Android's blur APIs change significantly in future releases.

Based on the file structure alone, no active development state is immediately apparent. The README and CHANGELOG exist but no recent PR templates or issue activity data is provided. The .github folder contains templates but no CI workflows, suggesting the repo is in maintenance mode rather than active feature development.

git clone https://github.com/wasabeef/Blurry.git
cd Blurry
gradle build
./gradlew installDebug  # or open in Android Studio and build the example module

Daily commands: Open example/src/main/AndroidManifest.xml and example/build.gradle — this is a standard Android app module. In Android Studio: open project root, select 'example' as run configuration, and run on an emulator or device. Or via CLI: ./gradlew example:installDebug && adb shell am start -n jp.wasabeef.example.blurry/.MainActivity

• blurry/src/main/java/jp/wasabeef/blurry/Blurry.java — Main entry point and fluent API builder for all blur operations; every user of the library starts here
• blurry/src/main/java/jp/wasabeef/blurry/Blur.java — Core blur algorithm implementation using RenderScript or Bitmap manipulation; handles actual pixel processing
• blurry/src/main/java/jp/wasabeef/blurry/BlurTask.java — Async task orchestration layer; manages threading and background blur execution
• blurry/src/main/java/jp/wasabeef/blurry/BlurFactor.java — Configuration data class holding blur parameters (radius, sampling, color); passed through the pipeline
• blurry/src/main/java/jp/wasabeef/blurry/Helper.java — Utility functions for View/Bitmap conversion and dimension calculations; supports blur pipeline
• blurry/build.gradle — Library build configuration and dependency declarations; controls compilation and packaging
• example/src/main/java/jp/wasabeef/example/blurry/MainActivity.kt — Primary example demonstrating all blur library usage patterns; reference for API consumers

• Blurry (Java, Android Context) — Singleton-style fluent API facade; orchestrates builder pattern, stores config, delegates to BlurTask
  • Failure mode: Invalid parameters (negative radius, null view) raise IllegalArgumentException
• BlurTask (AsyncTask or Executor, Android Handler) — Async execution layer; runs blur off UI thread, handles callbacks, manages Bitmap lifecycle
  • Failure mode: OOM if Bitmap allocation fails; caught and logged, blur silently fails unless callback is registered
• Blur (RenderScript (ScriptIntrinsicBlur), Bitmap, Canvas) — Core algorithm; applies RenderScript convolution or CPU-based pixelwise blur to Bitmap

Add a new blur filter type (e.g., Gaussian, Motion Blur)

1. Add static method or new algorithm to Blur.java for the new filter type (blurry/src/main/java/jp/wasabeef/blurry/Blur.java)
2. Extend BlurFactor.java to store new filter parameters (blurry/src/main/java/jp/wasabeef/blurry/BlurFactor.java)
3. Add fluent builder method to Blurry.java (e.g., filterType()) to expose the new option (blurry/src/main/java/jp/wasabeef/blurry/Blurry.java)
4. Invoke the new filter in BlurTask.java during async execution (blurry/src/main/java/jp/wasabeef/blurry/BlurTask.java)

Support a new input source (e.g., blurring from drawable resource)

1. Add overloaded builder method in Blurry.java (e.g., fromDrawable()) to accept new source (blurry/src/main/java/jp/wasabeef/blurry/Blurry.java)
2. Add conversion utility in Helper.java to transform drawable/resource to Bitmap (blurry/src/main/java/jp/wasabeef/blurry/Helper.java)
3. Store input state in BlurFactor.java so pipeline can access the source (blurry/src/main/java/jp/wasabeef/blurry/BlurFactor.java)
4. Test with MainActivity.kt example to verify end-to-end workflow (example/src/main/java/jp/wasabeef/example/blurry/MainActivity.kt)

Optimize blur performance or add caching

1. Analyze BlurTask.java execution path and identify where caching or memoization applies (blurry/src/main/java/jp/wasabeef/blurry/BlurTask.java)
2. Enhance BlurFactor.java with cache-key generation (hash of radius, sampling, dimensions) (blurry/src/main/java/jp/wasabeef/blurry/BlurFactor.java)
3. Add LRU or weak-reference cache in Blur.java to store pre-computed blurred bitmaps (blurry/src/main/java/jp/wasabeef/blurry/Blur.java)
4. Update Blurry.java fluent API to optionally enable/disable caching per blur operation (blurry/src/main/java/jp/wasabeef/blurry/Blurry.java)

• RenderScript — Hardware-accelerated blur via GPU intrinsics (ScriptIntrinsicBlur); provides fast convolution on supported devices
• AsyncTask / Background Threading — Blur operations are CPU/GPU intensive; async prevents UI thread blocking and maintains app responsiveness
• Fluent Builder Pattern — Provides readable, chainable API for complex parameter configuration (radius, sampling, color, animation)
• Bitmap & Canvas — Core Android primitives for capturing View pixels and compositing blurred output onto targets

• Blur-on-demand (no built-in caching)

  • Why: Keeps library lightweight and memory-efficient; avoids large bitmap cache overhead
  • Consequence: Repeated blur of same content recalculates; callers must implement own cache if needed

• Synchronous blur capture from Views (capture method) vs overlay (onto method)

  • Why: Supports both snapshot and live-blur workflows without forcing one architecture
  • Consequence: Overlay can be slower on complex hierarchies; capture is one-shot and disconnected from view updates

• Optional RenderScript with fallback to bitmap ops

  • Why: Maximizes compatibility (RenderScript deprecated in API 31) while maintaining performance on older APIs
  • Consequence: Runtime detection overhead; fallback slower on devices without RenderScript acceleration

• Real-time video/stream blur (library works on static Bitmaps and View snapshots, not frame-by-frame)
• Blur editing UI or parameters adjustment after apply (immutable blur once set)
• Integration with image loading libraries (caller must convert loaded image to Bitmap)
• Blur-to-file or persistent blur caching (operates in-memory only)

RenderScript deprecation: Android has deprecated RenderScript in favor of Vulkan/compute shaders, but Blurry still relies on it. Verify which blur path is active on your target Android version in Blur.java. Bitmap lifecycle: calling .get() or .getAsync() creates a new bitmap; you own memory management — no automatic recycling. ViewGroup requirement: .onto(rootView) only works if rootView is a ViewGroup; Views will crash silently. Sampling interaction: high sampling values combined with large blur radius can cause OOM on low-memory devices; no built-in memory guards. Missing test suite: no junit or instrumentation tests visible in the file list; behavior regressions are not automated.

• RenderScript — Blurry's primary blur engine; understanding how RenderScript kernels execute parallel SIMD operations on textures is essential to troubleshooting performance and understanding why the library is fast but now deprecated
• Downsampling (texture mipmap) — The sampling(n) parameter reduces input bitmap resolution before blur to trade quality for speed; critical for device memory and performance tuning
• Gaussian blur (image convolution kernel) — The math behind the blur effect; understanding separable convolution and kernel radius is needed to predict visual results and performance
• ViewGroup overlay composition — The .onto(rootView) mode composites a blurred bitmap layer on top of an existing ViewGroup; requires understanding Android's View hierarchy and layer rendering
• Async task and callback pattern — BlurTask.java implements background blur processing to avoid ANR; understanding task cancellation, callback safety, and lifecycle binding prevents crashes
• Bitmap memory pooling — Blur operations allocate large bitmap objects; understanding when to recycle and reuse bitmaps is critical to prevent OOM exceptions on low-memory devices

• Manuelpop/blurview — Alternative blur overlay library using OpenGL rendering instead of RenderScript; smaller dependencies but less documented
• 500px/BlurredView — Older blur library using Renderscript with slightly different API; reference for RenderScript patterns on Android
• square/picasso — Image loading library often paired with Blurry for efficient bitmap sourcing and memory management
• google/android-architecture — Google's MVVM/MVP samples; reference for how to architect Android apps using libraries like Blurry in production
• wasabeef/glide-transformations — Companion library by the same author providing Glide integration for image transformations; shows complementary use cases

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 BlurTask and Blur classes

The core blur functionality in blurry/src/main/java/jp/wasabeef/blurry/Blur.java and BlurTask.java lacks automated test coverage. Given this is a library with async blur operations, instrumented tests would verify correctness of blur radius application, bitmap handling, and async callback behavior across different API levels and device configurations.

• [ ] Create blurry/src/androidTest/java/jp/wasabeef/blurry/ directory structure
• [ ] Write BlurTaskTest.java testing async blur execution, callback invocation, and bitmap lifecycle
• [ ] Write BlurTest.java testing blur radius application, sampling factors, and edge cases (null bitmaps, invalid radii)
• [ ] Add AndroidJUnit4 and androidx.test dependencies to blurry/build.gradle
• [ ] Verify tests run on minSdkVersion and modern API levels

Add GitHub Actions workflow for continuous integration and automated releases

The repo has placeholder PR/Issue templates and Maven Central publishing configured, but no CI/CD pipeline. A GitHub Actions workflow would automatically run tests, verify builds on each PR, and streamline the maven-central-v1.gradle release process mentioned in the config.

• [ ] Create .github/workflows/ci.yml to run ./gradlew build and instrumented tests on push/PR
• [ ] Create .github/workflows/release.yml triggered on version tag (v*) to publish to Maven Central using the existing gradle config
• [ ] Add secrets configuration for Maven Central credentials (SONATYPE_USERNAME, SONATYPE_PASSWORD) in repo settings
• [ ] Test the workflow by creating a test release tag and verifying artifact appears in Maven Central
• [ ] Document the release process in CONTRIBUTING.md

Add unit tests for BlurFactor and Helper classes

BlurFactor.java and Helper.java contain business logic for blur parameter validation and utility operations but lack unit test coverage. These are good candidates for pure JVM unit tests that verify parameter calculation, edge case handling, and helper method behavior without needing instrumentation.

• [ ] Create blurry/src/test/java/jp/wasabeef/blurry/ directory structure
• [ ] Write BlurFactorTest.java testing radius validation, sampling calculation, and boundary conditions
• [ ] Write HelperTest.java testing any bitmap dimension calculations, resource utilities, or parameter conversion methods
• [ ] Add JUnit4 and Mockito dependencies to blurry/build.gradle testImplementation
• [ ] Ensure tests are executable via ./gradlew test and integrated into CI workflow

• Add unit tests under blurry/src/test/ for BlurFactor.java and Helper.java utility functions. These are pure Java classes with no Android dependencies, making them ideal for JUnit testing. Start with tests for sampling calculation logic.: The repo has no visible test directory, and blur calculations are safety-critical for OOM prevention.
• Add Kotlin extension functions in a new file blurry/src/main/java/jp/wasabeef/blurry/BlurryExt.kt to provide idiomatic Kotlin syntax (e.g., view.blur(radius = 10, sampling = 2) instead of Blurry.with(context).radius(10).sampling(2).onto(view)). Mirror the fluent API as receiver extensions.: The library is predominantly Java but the example app uses Kotlin; seamless Kotlin ergonomics would improve adoption.
• Document the RenderScript backend vs. platform blur fallback in README.md with a table showing which blur method is used per API level (21-31+). Add a troubleshooting section explaining sampling/radius tradeoffs and OOM prevention.: README shows only happy-path examples; users lack guidance on performance tuning, and the RenderScript deprecation path is undocumented.

The Blurry library codebase demonstrates good security practices overall, with no critical vulnerabilities detected. The main concern is the use of externally-hosted Gradle scripts without integrity verification, which introduces a moderate supply-chain risk. The presence of debug keystores and developer contact information in version control represents low-severity configuration issues. The codebase itself (based on file structure) appears to be a straightforward UI library without complex data handling, injection points, or hardcoded secrets. Recommendations focus on improving build supply-chain security and removing unnecessary metadata from version control.

• Medium · Insecure Gradle Script Source — blurry/build.gradle, line with 'apply from: https://gist.githubusercontent.com/wasabeef/2f2ae8d97b429e7d967128125dc47854/raw/maven-central-v1.gradle'. The build.gradle file loads a Maven Central configuration script from a GitHub gist via HTTPS without integrity verification. While HTTPS provides transport security, there is no checksum validation of the downloaded script. A compromised gist or man-in-the-middle attack could inject malicious build logic. Fix: Implement one of the following: (1) Host the gradle script in a private repository with access controls, (2) Download and verify the script locally with a checksum, (3) Use Gradle's built-in signing and verification mechanisms, or (4) Inline critical build configuration directly in the build.gradle file.
• Low · Commented Legacy Deployment Configuration — blurry/build.gradle, lines with TODO and commented Bintray references. The build.gradle file contains commented-out Bintray deployment configuration that references archived/sunset services. While commented, this could be accidentally uncommented or serve as a reference for insecure deployment patterns. Fix: Remove the commented-out Bintray configuration entirely. Maintain a separate CHANGELOG or migration documentation if needed for historical reference. The existing Maven Central configuration is the correct modern approach.
• Low · Debug Keystore in Version Control — signingConfigs/debug.keystore. A debug keystore file (signingConfigs/debug.keystore) is present in the repository. While debug keystores are typically safe (default credentials are widely known), storing any keystore in version control is poor practice and could be problematic if ever modified for other purposes. Fix: Remove the keystore from version control and add it to .gitignore. Add documentation on how developers should generate their own debug keystores locally. Reserve keystore files for local-only generation or secure CI/CD systems with proper secrets management.
• Low · Developer Email Exposure — blurry/build.gradle, developerEmail property. The developer's email address (dadadada.chop@gmail.com) is hardcoded and publicly visible in the build.gradle configuration. Fix: Consider removing the developer email from the build.gradle file or using a placeholder. If contact information is necessary, maintain it in a separate MAINTAINERS.md file or project metadata rather than in build configuration.

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.