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/Blankj/AndroidUtilCode 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

• 18 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 58% of recent commits

_{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 Blankj/AndroidUtilCode repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Blankj/AndroidUtilCode.

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

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

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

# 4. Critical files exist
test -f "build.gradle" \\
  && ok "build.gradle" \\
  || miss "missing critical file: build.gradle"
test -f "buildSrc/src/main/groovy/Config.groovy" \\
  && ok "buildSrc/src/main/groovy/Config.groovy" \\
  || miss "missing critical file: buildSrc/src/main/groovy/Config.groovy"
test -f "feature/main/pkg/src/main/java/com/blankj/main/pkg/MainActivity.kt" \\
  && ok "feature/main/pkg/src/main/java/com/blankj/main/pkg/MainActivity.kt" \\
  || miss "missing critical file: feature/main/pkg/src/main/java/com/blankj/main/pkg/MainActivity.kt"
test -f "buildSrc/src/main/java/com/blankj/plugin/readme/ReadmeCorePlugin.groovy" \\
  && ok "buildSrc/src/main/java/com/blankj/plugin/readme/ReadmeCorePlugin.groovy" \\
  || miss "missing critical file: buildSrc/src/main/java/com/blankj/plugin/readme/ReadmeCorePlugin.groovy"
test -f "feature/mock/src/main/java/com/blankj/mock/utilcode/UtilCodeApiMock.java" \\
  && ok "feature/mock/src/main/java/com/blankj/mock/utilcode/UtilCodeApiMock.java" \\
  || miss "missing critical file: feature/mock/src/main/java/com/blankj/mock/utilcode/UtilCodeApiMock.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 661 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~631d)"
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/Blankj/AndroidUtilCode"
  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).

AndroidUtilCode is a comprehensive Android utility library that encapsulates ~200+ commonly-used Android development functions (file ops, thread management, device info, encryption, logging, etc.) into a dual-module structure: lib/utilcode for frequently-used utilities and lib/subutil for specialized functions. It reduces boilerplate in Android development by providing tested, documented API wrappers around repetitive Android framework tasks. Multi-module Gradle monorepo: lib/utilcode/ and lib/subutil/ contain the core utility libraries (organized by function type: SpUtil, FileUtil, ThreadUtil, etc. as evident from README structure), feature/launcher/app/ is the demo application, and buildSrc/ contains custom Gradle plugins (including a custom ReadmeCorePlugin in buildSrc/src/main/java/com/blankj/plugin/readme/) for documentation generation. Each utility is a self-contained static class with no inter-dependencies.

Android developers building production apps who need battle-tested, zero-dependency utility functions for common tasks (SharedPreferences access, file I/O, device metadata, date/time formatting, encryption) without writing and maintaining these helpers themselves. Particularly valuable for teams shipping consumer Android apps at scale.

Highly mature and production-ready. The repo has 30.6k+ stars on GitHub, active CI/CD via GitHub Actions (.github/workflows/android.yml), comprehensive unit tests, and consistent commit history. The codebase is 2.37M LOC in Java plus 256k in Kotlin, indicating years of refinement. However, last major activity should be verified—check the CHANGELOG.md and recent PR merge dates.

Low risk for core functionality, but single-maintainer dependency (Blankj) creates long-term sustainability questions if the author steps back. The library has minimal external dependencies (by design—see allprojects in build.gradle), reducing supply-chain risk. No major breaking changes evident in structure, though the dual-module split (utilcode vs. subutil) can confuse new users about which APIs are stable.

The repo is actively maintained with regular updates tracked in CHANGELOG.md. GitHub Actions CI runs on every commit (.github/workflows/android.yml handles Android builds). Specific recent work is not visible in the provided file list, but the presence of dual issue templates (bug_report.md, feature-request.md in both English and Chinese variants) suggests active community engagement. Check GitHub issues and recent commit log for concrete current work.

git clone https://github.com/Blankj/AndroidUtilCode.git
cd AndroidUtilCode
./gradlew build
./gradlew :feature:launcher:app:installDebug  # Install demo app on emulator/device

Note: Requires Android SDK (API 14+, per badge), Java 8+, and Android Studio or CLI Gradle.

Daily commands: This is a library, not an app—no 'run' in traditional sense. For the demo launcher app: ./gradlew :feature:launcher:app:installDebug && adb shell am start -n com.blankj.utilcode/.MainActivity (adjust package name per AndroidManifest.xml). To run tests: ./gradlew test (for unit tests across modules).

• build.gradle — Top-level build configuration that orchestrates all subprojects, repositories, and dependency resolution strategies—all changes flow through here
• buildSrc/src/main/groovy/Config.groovy — Central configuration management for the entire build system; defines build flavors, versions, and project structure
• feature/main/pkg/src/main/java/com/blankj/main/pkg/MainActivity.kt — Primary entry point for the main application feature demonstrating the utilcode library in production
• buildSrc/src/main/java/com/blankj/plugin/readme/ReadmeCorePlugin.groovy — Custom Gradle plugin that auto-generates README documentation from utility metadata—critical for project documentation automation
• feature/mock/src/main/java/com/blankj/mock/utilcode/UtilCodeApiMock.java — Mock layer that provides test doubles for all utilcode utilities, enabling isolated testing and demo functionality
• .github/workflows/android.yml — CI/CD pipeline definition that validates builds, runs tests, and ensures code quality on every commit
• settings.gradle — Root Gradle settings file that declares all modules (launcher, main, subutil) and their interdependencies

Add a New Utility Class to utilcode

1. Create new utility class in feature/main/pkg/src/main/java/com/blankj/main/pkg/ following naming convention (e.g., LogUtil.kt) (feature/main/pkg/src/main/java/com/blankj/main/pkg/)
2. Add corresponding mock implementation in feature/mock/src/main/java/com/blankj/mock/utilcode/ to provide test doubles (feature/mock/src/main/java/com/blankj/mock/utilcode/UtilCodeApiMock.java)
3. Create demonstration code in MainActivity.kt to showcase the new utility in action (feature/main/pkg/src/main/java/com/blankj/main/pkg/MainActivity.kt)
4. Add documentation entry in README.md under the appropriate utility category with usage examples (README.md)
5. Run ReadmeCorePlugin to auto-generate documentation: ./gradlew readmeCore task will parse annotations (buildSrc/src/main/java/com/blankj/plugin/readme/ReadmeCorePlugin.groovy)

Add a New Rare-Use Utility to subutil Module

1. Create utility class in feature/subutil/app/src/main/java/com/blankj/subutil/pkg/ with clear responsibility separation (feature/subutil/app/src/main/java/)
2. Add mock implementation in feature/mock/src/main/java/com/blankj/mock/subutil/SubUtilApiMock.java (feature/mock/src/main/java/com/blankj/mock/subutil/SubUtilApiMock.java)
3. Update buildSrc/src/main/groovy/ModuleConfig.groovy to register the new module if creating a new submodule (buildSrc/src/main/groovy/ModuleConfig.groovy)
4. Add usage documentation to README-CN.md and README.md in the subutil section (README.md)

Extend Build System Configuration

1. Define new build variables or flavor configurations in buildSrc/src/main/groovy/Config.groovy (buildSrc/src/main/groovy/Config.groovy)
2. Create flavor-specific build settings in config/flavor.gradle if new build variants needed (config/flavor.gradle)
3. Update feature-specific build.gradle files to inherit the new configuration (buildApp.gradle)
4. Verify CI/CD integration by adding validation steps to .github/workflows/android.yml (.github/workflows/android.yml)

• Android Gradle Build System — Industry standard for Android project configuration, multi-module support, and dependency management with extensive plugin ecosystem
• Kotlin + Java — Kotlin modernizes the codebase while maintaining Java interoperability; both are first-class citizens in Android development
• Custom Gradle Plugins (ReadmeCorePlugin) — Automates documentation generation and keeps README in sync with code, reducing manual maintenance and documentation drift
• GitHub Actions CI/CD — Native GitHub integration for automated testing, validation, and quality checks on every commit without external infrastructure
• Mock Framework (feature/mock) — Enables isolated testing and demonstration of utilities without external dependencies; facilitates unit test independence

• Monorepo structure with multiple feature modules (launcher, main, subutil) instead of separate repositories

  • Why: Simplifies dependency management, ensures atomic changes, and eases cross-module refactoring
  • Consequence: Larger repository size and longer clone times; requires careful CI/CD configuration to avoid cascading failures

• Custom Gradle plugins in buildSrc instead of published plugins

  • Why: Tighter integration with project structure, immediate feedback during development, and project-specific customization
  • Consequence: Build scripts become project-specific and harder to reuse across other projects; buildSrc dependency maintenance required

• Mock layer as a dedicated feature module rather than test fixtures

  • Why: Allows mock utilities to be used in demo apps and UI showcases, not just unit tests
  • Consequence: Mock implementations must be maintainable and follow same code standards as production code

• Automated README generation via ReadmeCorePlugin

  • Why: Ensures documentation consistency with implementation; reduces documentation debt and manual sync errors
  • Consequence: Documentation quality depends on annotation discipline; missing/incomplete annotations degrade output

• Does not provide runtime dependency injection—utilities are static/singleton utilities meant to be called directly
• Does not implement network communication APIs—focuses on local device utilities only
• Does not provide UI framework or view bindings—utilities are low-level device/system APIs, not UI helpers
• Does not handle backend authentication or user management—purely client-side utility library
• Does not support iOS or cross-platform development—Android-specific utilities only

1. Custom Gradle plugins in buildSrc/: Modifications to Config.groovy or ConfigUtils.groovy affect the entire build. Changes here can silently break all module builds. 2. Dual-language documentation: Both README.md (English) and README-CN.md (Chinese) exist—keep them in sync or users will see inconsistent info. 3. Auto-generated docs: The ReadmeCorePlugin generates parts of README.md from annotations; editing README directly may be overwritten. 4. API level 14 minimum: Utils must remain backward-compatible to Android API 14 (per badge)—avoid newer APIs without proper checks. 5. No external dependencies by design: The library intentionally has zero runtime dependencies; introducing any will break this key selling point. 6. buildSrc/ changes require clean rebuild: Modifying Groovy code in buildSrc/ may not refresh in Gradle daemon—run ./gradlew --stop && ./gradlew build to force rebuild.

• SharedPreferences Wrapper Pattern (SpUtil) — Demonstrates how AndroidUtilCode abstracts Android's low-level SharedPreferences API into a thread-safe, type-safe singleton utility—essential to understand if you need to add new preference-based utilities or modify SpUtil.
• Gradle Plugin Development (Custom DSL in buildSrc/) — This repo uses custom Groovy-based Gradle plugins (Config.groovy, ReadmeCorePlugin) to automate builds and documentation—understanding how these work is critical to modifying the build system or adding new module types.
• Thread Pool Management (ThreadUtil) — AndroidUtilCode abstracts Java's ExecutorService patterns for safe background task execution on Android—learning how ThreadUtil manages thread lifecycle helps avoid common concurrency bugs in Android apps.
• Android Permission Model (PermissionUtil) — Encapsulates the runtime permission checking required in Android 6.0+ (API 23+)—critical for understanding if you modify PermissionUtil or add permission-dependent utilities.
• Reflection-based Utility Inspection — Several utilities (e.g., DeviceUtil, ProcessUtil) use Java reflection to introspect system properties and running processes—understanding reflection is necessary to modify these utilities safely and avoid security/performance issues.
• Annotation-based Documentation Generation (ReadmeCorePlugin) — The ReadmeCorePlugin parses JavaDoc annotations in utility classes to auto-generate README sections—understanding this pattern helps you add new utilities that are automatically documented.

• Kotlin/kotlinx — Complementary ecosystem of Kotlin extensions and stdlib utilities; AndroidUtilCode should ideally leverage or align with kotlinx.coroutines, kotlinx.serialization for Kotlin users.
• square/okhttp — Networking utility library that follows similar philosophy (minimalist, tested, widely-used)—if AndroidUtilCode were to add HTTP utilities, this is the production-grade reference.
• google/guava — General-purpose Java utility library (Collections, Preconditions, Hashing); some AndroidUtilCode functions mirror Guava APIs—understanding Guava helps recognize which utils are novel vs. Guava-equivalent.
• JakeWharton/butterknife — Android view-binding library that reduces boilerplate; complementary to AndroidUtilCode (ButterKnife handles UI injection, AndroidUtilCode handles non-UI utilities).
• Blankj/AucFrameTemplate — Referenced in README as a template for building custom Android projects using AndroidUtilCode; example application showing best practices for integrating the library.

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 comprehensive unit tests for buildSrc Gradle plugin utilities

The buildSrc directory contains critical build infrastructure (Config.groovy, ConfigUtils.groovy, LibConfig.groovy, ModuleConfig.groovy, PluginConfig.groovy) that lacks visible test coverage. These Groovy files handle build configuration and the custom README plugin. Adding unit tests would prevent regressions when modifying build logic and serve as documentation for how the build system works.

• [ ] Create buildSrc/src/test directory structure matching buildSrc/src/main
• [ ] Add unit tests for ConfigUtils.groovy covering initialization and plugin application
• [ ] Add tests for Config.groovy verifying version management and dependency resolution
• [ ] Add tests for ReadmeCorePlugin.groovy and ReadmeSubPlugin.groovy to validate README generation
• [ ] Integrate tests into buildSrc/build.gradle with test task configuration

Add GitHub Actions workflow for Gradle dependency vulnerability scanning

The repo has .github/workflows/android.yml for builds, but lacks automated dependency security checks. Given this is a widely-used utility library with many dependencies (evident from build.gradle and allprojects repositories), adding a OWASP Dependency-Check or Gradle dependency-check plugin workflow would help catch vulnerable transitive dependencies before they reach users.

• [ ] Create .github/workflows/dependency-check.yml
• [ ] Configure OWASP Dependency-Check action or gradle-dependency-check plugin
• [ ] Set workflow to run on pull_request and scheduled (weekly)
• [ ] Configure failure conditions and generate security reports
• [ ] Update README.md with badge/status for dependency scanning results

Create feature module integration tests and document multi-module architecture

The repo contains feature/launcher and feature/main modules alongside the main utilcode and subutil modules, but there's no visible documentation explaining the multi-module architecture or integration tests validating module interactions. This creates friction for new contributors understanding module relationships.

• [ ] Add architecture documentation in README.md explaining feature/launcher, feature/main, utilcode, and subutil relationships
• [ ] Create buildSrc integration tests validating ModuleConfig.groovy correctly references all feature modules
• [ ] Add androidTest cases in feature modules verifying cross-module dependencies work correctly
• [ ] Document dependency graph in a diagram (consider adding to art/ directory)
• [ ] Update CONTRIBUTING.md with instructions for adding new feature modules

• Add test coverage for [specific utility]: Many utils in lib/utilcode/src/main/java/com/blankj/utilcode/util/ (e.g., DeviceUtil, ProcessUtil, PermissionUtil) lack comprehensive unit tests. Pick an undertested utility, write edge-case tests (null inputs, empty collections, permission denied scenarios) in lib/utilcode/src/test/java/, and submit as PR. This is low-risk, high-value.
• Improve documentation with code examples: Review lib/utilcode/README.md and identify utilities with minimal usage examples (e.g., ThreadUtil, BusUtil). Add concrete code snippets from feature/launcher/app/src/main/ or create new demo snippets in README.md. Both English (README.md) and Chinese (README-CN.md) versions need updates.
• Add Kotlin extension functions for frequently-used utilities: The Kotlin/ directory (256k LOC) is underdeveloped relative to Java utils. Create Kotlin extensions (e.g., SharedPreferences extensions via SpUtil, File extensions via FileUtil) in a new lib/utilcode-kotlin/ module to make the library more idiomatic for Kotlin developers. This aligns with the repo's Kotlin adoption goal.

The AndroidUtilCode codebase has several build and dependency management security concerns. The most critical issues are the use of deprecated jcenter() repository, unversioned plugin dependencies, and lack of dependency verification mechanisms. The project should prioritize removing jcenter(), implementing explicit version pinning for all build plugins, and enabling Gradle's dependency verification features. The custom build configuration in buildSrc provides flexibility but requires better documentation and security controls. Overall security posture is moderate with room for improvement in supply chain security.

• High · Deprecated jcenter() Repository — build.gradle (lines with jcenter()). The build.gradle file includes 'jcenter()' repository which has been deprecated and shut down by JFrog. This can lead to build failures and prevents access to updates from this source. Additionally, using deprecated repositories increases the risk of supply chain attacks. Fix: Remove all instances of 'jcenter()' from the build configuration. Ensure all dependencies are available from 'mavenCentral()' or 'google()' repositories.
• High · Unversioned Plugin Dependencies — build.gradle (buildscript dependencies section). The buildscript configuration dynamically applies classpath dependencies from ConfigUtils.getApplyPlugins() without explicit version pinning. This can lead to unexpected version changes and potential security issues from vulnerable plugin versions. Fix: Explicitly specify and pin versions for all build plugins. Review the ConfigUtils.groovy file to ensure all plugin dependencies have locked versions and are from trusted sources.
• Medium · Overly Permissive Dependency Resolution Strategy — build.gradle (allprojects configurations section). The resolutionStrategy.cacheChangingModulesFor is set to 0 seconds, which means changing modules are never cached. Combined with dynamic dependency resolution, this could allow man-in-the-middle attacks if network connections are compromised. Fix: Set an appropriate cache duration (e.g., 24 hours) for changing modules: 'resolutionStrategy.cacheChangingModulesFor 24, 'hours'. Use only HTTPS repositories and implement certificate pinning for critical dependencies.
• Medium · Missing Repository Authentication — build.gradle (maven { url "https://jitpack.io" } line). The build.gradle includes a custom JitPack repository without explicit authentication or verification mechanism. JitPack builds packages directly from GitHub, which could be exploited if source repositories are compromised. Fix: Verify that JitPack dependencies are from trusted sources. Consider using credential management for private repositories. Implement dependency verification using Gradle's built-in verification mechanisms.
• Medium · No Dependency Verification — build.gradle and buildSrc configuration. There is no evidence of dependency verification (checksum verification, GPG signing verification) in the build configuration. This increases the risk of supply chain attacks through compromised dependencies. Fix: Enable Gradle dependency verification by creating a gradle/verification-metadata.xml file. Verify checksums and signatures of critical dependencies. Consider using Gradle's built-in dependency lock file feature.
• Low · Hardcoded Support Library Version Management — build.gradle (resolutionStrategy.eachDependency section). While the code uses Config.supportVersion for centralized management, the pattern shows dependencies are managed through dynamic Groovy scripts, making it harder to audit and track security updates. Fix: Consider using a dependency lock file (like gradle.lockfile) or a separate dependencies.gradle file with explicit version declarations that are easier to audit and update.
• Low · Missing Build Configuration Documentation — buildSrc/ directory structure. Complex build configuration with custom Groovy scripts in buildSrc lacks clear documentation about configuration sources and security implications. Fix: Add security documentation for the build process. Document all custom Gradle plugins and configuration sources. Include security best practices in contribution guidelines.

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.