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/wyouflf/xUtils3 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 — Looks unmaintained — solo project with stale commits

• Other licensed
• Tests present
• ⚠ Stale — last commit 4y ago
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ Non-standard license (Other) — review terms
• ⚠ 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 wyouflf/xUtils3 repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/wyouflf/xUtils3.

What it runs against: a local clone of wyouflf/xUtils3 — 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 wyouflf/xUtils3 | Confirms the artifact applies here, not a fork | | 2 | License is still Other | 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 ≤ 1541 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other 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 "xutils/src/main/java/org/xutils/DbManager.java" \\
  && ok "xutils/src/main/java/org/xutils/DbManager.java" \\
  || miss "missing critical file: xutils/src/main/java/org/xutils/DbManager.java"
test -f "xutils/src/main/java/org/xutils/HttpManager.java" \\
  && ok "xutils/src/main/java/org/xutils/HttpManager.java" \\
  || miss "missing critical file: xutils/src/main/java/org/xutils/HttpManager.java"
test -f "xutils/src/main/java/org/xutils/ImageManager.java" \\
  && ok "xutils/src/main/java/org/xutils/ImageManager.java" \\
  || miss "missing critical file: xutils/src/main/java/org/xutils/ImageManager.java"
test -f "xutils/src/main/java/org/xutils/common/task/PriorityExecutor.java" \\
  && ok "xutils/src/main/java/org/xutils/common/task/PriorityExecutor.java" \\
  || miss "missing critical file: xutils/src/main/java/org/xutils/common/task/PriorityExecutor.java"
test -f "xutils/src/main/java/org/xutils/cache/LruDiskCache.java" \\
  && ok "xutils/src/main/java/org/xutils/cache/LruDiskCache.java" \\
  || miss "missing critical file: xutils/src/main/java/org/xutils/cache/LruDiskCache.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 1541 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1511d)"
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/wyouflf/xUtils3"
  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).

xUtils3 is a lightweight (~251KB) Android utility library that bundles ORM, HTTP(S) client, image loading, and view annotation binding into a single dependency. It provides efficient database operations with LINQ-like query syntax, robust HTTP support (11 HTTP verbs, 2GB+ file uploads, range-based resumable downloads, cookie/cache management), and intelligent image caching with ListView-aware auto-cancellation. Monolithic structure: xutils3 core library (not shown but inferred from dependency layout) alongside a comprehensive demo/ module. Demo contains BaseActivity/BaseFragment, feature-specific activities (DbFragment, HttpFragment, ImageFragment, DownloadActivity), and example implementations (db models Parent/Child, download manager with state converters, JSON request/response builders). This mirrors a typical AndroidX lib + sample layout.

Android developers building production apps who need modular support for database persistence, network operations, image display, and view injection without pulling in fragmented dependencies. Particularly useful for teams shipping apps that require sophisticated cookie handling, resumable downloads, and responsive image loading with proper memory management.

Actively maintained and production-ready. The repository shows 436K lines of Java code with a stable 3.9.0 version on Maven Central (bintray distribution). However, the visible file structure suggests the last major activity was around 2020-2021; while there is no indication of abandonment, commit frequency appears moderate rather than daily.

Single-maintainer repository (wyouflf) with no visible GitHub Actions CI pipeline in the build configuration (uses manual Gradle + Bintray publishing). The codebase is mature but updates are infrequent, creating risk if critical Android OS changes require urgent fixes. No visible unit test directory in the top 60 files, suggesting test coverage may be limited.

No recent activity visible in the provided file manifest. The last detectable state is the working demo with all four major modules (ORM, HTTP, Image, View Injection) functional. No open PRs or active issues are mentioned in the snippet provided.

git clone https://github.com/wyouflf/xUtils3.git
cd xUtils3
./gradlew build
./gradlew :demo:assembleDebug
# Or open in Android Studio and run demo/ module directly

Daily commands:

# Build library
./gradlew xutils:build

# Run demo app on connected device/emulator
./gradlew :demo:installDebug :demo:connectedAndroidTest

# Or in Android Studio: Select demo module, click Run

• xutils/src/main/java/org/xutils/DbManager.java — Entry point for ORM operations; all database queries and schema management flow through this manager
• xutils/src/main/java/org/xutils/HttpManager.java — Core HTTP client manager handling all network requests, caching, cookies, and download logic
• xutils/src/main/java/org/xutils/ImageManager.java — Image loading and caching orchestrator; manages memory and disk cache for all image binding operations
• xutils/src/main/java/org/xutils/common/task/PriorityExecutor.java — Thread pool executor that manages task scheduling and priority-based execution across all async operations
• xutils/src/main/java/org/xutils/cache/LruDiskCache.java — Disk caching layer implementing LRU eviction for HTTP responses and image thumbnails
• xutils/src/main/java/org/xutils/ViewInjector.java — Annotation processing engine for view injection and event binding; enables declarative UI wiring
• xutils/src/main/java/org/xutils/common/Callback.java — Universal callback interface used across HTTP, image, and database async operations

Add a New HTTP Endpoint with Caching

1. Define a request params class with @HttpRequest annotation in your package (demo/src/main/java/org/xutils/demo/http/JsonDemoParams.java)
2. Create a Callback<YourResponseType> implementation to handle success/error/cancelled states (xutils/src/main/java/org/xutils/common/Callback.java)
3. Call HttpManager.post(url, params, callback) or similar verb; caching is automatic via LRU disk cache (xutils/src/main/java/org/xutils/HttpManager.java)
4. Override cache control headers in HttpManager if default LRU + expiry policy doesn't fit your endpoint (xutils/src/main/java/org/xutils/cache/LruDiskCache.java)

Add a New ORM Entity

1. Create a POJO class with @Table annotation and primary key field @Id (demo/src/main/java/org/xutils/demo/db/Parent.java)
2. Mark columns with @Column annotation for explicit mapping if needed; collections use @Foreign for relationships (demo/src/main/java/org/xutils/demo/db/Child.java)
3. Use DbManager.selector(YourEntity.class).where(...).findAll() for LINQ-style queries (xutils/src/main/java/org/xutils/DbManager.java)

Add View Injection and Event Binding

1. Annotate View fields with @ViewInject(id) in your Activity (demo/src/main/java/org/xutils/demo/BaseActivity.java)
2. Annotate event handler methods with @Event (e.g., @Event(R.id.buttonId, type=EventType.ItemClick)) (xutils/src/main/java/org/xutils/ViewInjector.java)
3. Call ViewInjector.inject(activity) once in onCreate() to bind all annotations (xutils/src/main/java/org/xutils/ViewInjector.java)

Customize Task Priority and Execution

1. Extend AbsTask<Result> and override doBackground()/onSuccess()/onError() lifecycle methods (xutils/src/main/java/org/xutils/common/task/AbsTask.java)
2. Set task priority via setPriority(Priority.HIGH/NORMAL/LOW) before submitting (xutils/src/main/java/org/xutils/common/task/Priority.java)
3. Submit task via TaskController.execute(task); PriorityExecutor queues it based on priority (xutils/src/main/java/org/xutils/common/task/PriorityExecutor.java)

• UrlConnection / OkHttp (Android 4.4+) — Provides HTTP/HTTPS with native Android integration; OkHttp handles connection pooling and modern protocols
• SQLite (via DbManager) — Lightweight embedded database standard on Android; ORM abstraction provides LINQ-style queries without greenDAO dependency
• LRU Caching (Memory + Disk) — Reduces redundant HTTP requests and disk I/O; dual-layer strategy fits mobile memory constraints and offline scenarios
• Priority-based Thread Pool (PriorityExecutor) — Ensures critical tasks (UI-bound image loads) execute before background syncs; prevents starvation on constrained Android devices

• Single unified HttpManager for all requests vs. per-domain managers

  • Why: Simplifies API and centralizes cookie/cache policy; all requests benefit from global LRU eviction
  • Consequence: Less granular control per endpoint; must override policies at HttpManager level or subclass Callback

• Annotation-based view injection (runtime reflection) vs. generated code (APT)

  • Why: Keeps library lightweight (251K); avoids build-time dependency
  • Consequence: Slight runtime overhead on activity creation; not affected by ProGuard if configured correctly per consumer-rules.pro

• LRU disk cache with expiry + LRU double cleanup vs. just LRU

  • Why: Cache-Control headers must be honored for HTTP spec compliance; prevents unbounded disk growth
  • Consequence: Cache entries checked twice for eviction; adds ~10ms lookup overhead on large disk caches

• Support for 11 HTTP verbs + Range-based resume vs. simple GET/POST

  • Why: Enables RESTful APIs and large file uploads/downloads without external libraries
  • Consequence: Increased surface area; more code paths to test and maintain

• Real-time synchronization (no WebSocket/streaming built-in; use OkHttp interceptors or RxJava adapters)
• Authentication/encryption (leave to HTTPS + custom headers; cookie support exists but no OAuth library)
• Reactive streams (no built-in RxJava; Callback interface is callback-based, not Observable)
• Multi-process database access (SQLite not designed for cross-process writes; single app process model assumed)
• Automatic schema migration (developer responsibility via DbManager transaction APIs)

1. Init required: x.Ext.init(context) MUST be called in Application.onCreate() or binding/HTTP will silently fail. 2. Permissions: INTERNET is mandatory; WRITE_EXTERNAL_STORAGE is optional but required for image/download disk caching. 3. GET retry behavior: GET requests retry 2 times by default (totaling 3 attempts), causing perceived 15s+ hangs on 5s timeout—setMaxRetryCount(0) disables this. 4. View annotation limitations: @Event methods must be private, parameters must exactly match the Listener interface signature, and same-ID subclass events override parent class handlers. 5. Image ListView performance: Auto-cancellation only works if ListView is properly configured; manual ViewHolder recycling won't trigger cancellation.

• LINQ-style query builder — The ORM selector() API uses fluent chaining (where, and, or, findAll) similar to LINQ; understanding this pattern is essential for writing xUtils3 database code without writing raw SQL
• HTTP Range requests & resumable downloads — xUtils3 auto-detects Range header support and handles partial downloads transparently; this is critical for the 2GB+ upload/download feature and understanding why slow networks recover gracefully
• LRU cache eviction with expiry dual-mechanism — HTTP response caching uses both time-based expiry (Cache-Control/Last-Modified) and LRU pruning; understanding this hybrid prevents cache staleness bugs and memory leaks
• View annotation binding (runtime reflection) — The @ViewInject, @Event, @ContentView system uses reflection to wire views/listeners without generated code; understanding this is needed to avoid ProGuard/R8 obfuscation issues (hence the consumer-rules.pro requirement)
• Cookie domain/path/expiry management — xUtils3 implements RFC 6265 cookie spec (domain matching, path scoping, expiry semantics) transparently; crucial for multi-domain apps or those interfacing with strict cookie policies
• ETag & Last-Modified HTTP cache validation — Beyond simple time-based caching, xUtils3 supports conditional GET using ETags and modification dates; understanding this prevents unnecessary re-downloads while ensuring freshness

• greenrobot/greenDAO — ORM alternative with equivalent performance claims; xUtils3 explicitly benchmarks against this for the 'greenDao-consistent performance' statement
• square/okhttp — Underlying HTTP implementation on Android 4.4+; xUtils3 wraps this transparently for cookie/cache logic
• bumptech/glide — Modern image loading competitor providing similar memory-aware ListView integration and disk caching, but more heavyweight than xUtils3's image module
• ReactiveX/RxJava — Async execution compatibility mentioned in README; users often pair xUtils3 HTTP calls with RxJava Observable chains
• wyouflf/xUtils — Predecessor/version 2 of this library; xUtils3 is a major rewrite with modular architecture

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for ORM database operations (DbFragment demo coverage)

The xUtils3 ORM module is a core feature (mentioned as 'high efficiency and stability') but there are no visible unit tests in the repository. The demo app has DbFragment.java and db models (Parent.java, Child.java) but no automated tests. Adding comprehensive unit tests for CRUD operations, query expressions, and relationship handling would catch regressions and improve contributor confidence.

• [ ] Create xutils/src/test/java/org/xutils/db/ directory structure
• [ ] Add DbTest.java with tests for insert, update, delete, query operations using Parent.java and Child.java models
• [ ] Add DbQueryTest.java testing the 'linq-like expression' query interface mentioned in README
• [ ] Add database transaction and relationship tests (Parent-Child foreign key operations)
• [ ] Update xutils/build.gradle to include JUnit and Android test dependencies
• [ ] Verify tests run with ./gradlew test

Add GitHub Actions CI/CD workflow for automated builds and testing

The repo uses Gradle (4.0.1) and has a demo app but no visible CI pipeline (.github/workflows/ directory missing). Given the library supports multiple Android API levels and has complex features (ORM, HTTP, image caching), automated testing across different configurations would prevent regressions and make the library more maintainable.

• [ ] Create .github/workflows/android-ci.yml for building the xutils module and demo app
• [ ] Add build matrix for API levels 21, 28, 29, 30+ as the library likely targets these ranges
• [ ] Include step to run unit tests and demo app Gradle builds
• [ ] Add Lint checks (Android lint) to catch potential API compatibility issues
• [ ] Configure workflow to trigger on pull requests and pushes to main branches

Document HTTP caching and cookie implementation details in wiki or dedicated guide

The README highlights cookie support (domain, path, expiry) and sophisticated caching (Cache-Control, Last-Modified, ETag, LRU) as key features, but the demo only shows HttpFragment.java without concrete examples. The codebase in xutils/ is not visible, but contributors need clear documentation on how to properly use these features to avoid misconfiguration. Add a specific guide with code examples.

• [ ] Create docs/HTTP_CACHING_GUIDE.md with examples of setting Cache-Control headers, handling ETag-based caching, and LRU eviction behavior
• [ ] Add docs/COOKIE_MANAGEMENT.md explaining domain/path filtering and expiry handling with code samples
• [ ] Reference actual implementation files when available (currently xutils/consumer-rules.pro and proguard configuration hint at complex HTTP/ORM logic)
• [ ] Include HttpFragment.java and JsonResponseParser.java usage patterns as practical examples
• [ ] Add troubleshooting section for common caching and cookie issues

• Add unit tests for the ORM selector API (demo/src/main/java/org/xutils/demo/db/ shows examples but no corresponding test/ directory exists in the visible structure)—start by writing tests for Parent/Child entity queries shown in README
• Document the custom request/response lifecycle by adding inline Javadoc examples to JsonDemoParams.java and JsonResponseParser.java, explaining how to extend the HTTP module for non-JSON payloads (e.g., Protocol Buffers, XML)
• Add missing demo for webp/gif image format handling mentioned in README—create a new GifImageFragment.java showing animated GIF display and single-frame fallback for older Android versions

The xUtils3 project has moderate security concerns primarily related to outdated build tooling and deprecated repositories. The main risks are: (1) Using Android Gradle Plugin 4.0.1 from 2020, which lacks modern security features; (2) Dependency on the defunct jc

• High · Outdated Gradle Build Tools — build.gradle (buildscript dependencies). The project uses Android Gradle Plugin version 4.0.1, which was released in 2020 and is significantly outdated. This version may contain known security vulnerabilities and lacks modern security features like dependency verification and supply chain protection. Fix: Update to the latest stable Android Gradle Plugin version (currently 8.x). Run 'gradle wrapper --gradle-version=<latest>' and update classpath 'com.android.tools.build:gradle' to version 8.1.0 or later.
• High · Deprecated Repository (jcenter) — build.gradle (allprojects repositories). The project uses jcenter() repository which was shut down by Bintray on May 1, 2021. Dependencies from this repository are no longer available, and it's a security risk to rely on deprecated package repositories. Fix: Remove jcenter() and use mavenCentral() or other active repositories. Update buildscript and allprojects blocks to use only google() and mavenCentral().
• Medium · Outdated Gradle Plugins — build.gradle (buildscript dependencies). The gradle-bintray-plugin (v1.8.4) and android-maven-gradle-plugin (v2.1) are outdated and unmaintained. These plugins may have unpatched security vulnerabilities. Fix: Replace deprecated plugins with modern alternatives. Consider using Maven Central publishing via gradle-maven-publish-plugin or official Gradle publishing plugins.
• Medium · Debug Keystore in Repository — demo/debug.keystore. A debug keystore file (debug.keystore) is present in the demo application directory and tracked in version control. While typically not sensitive, this indicates potential for accidental exposure of signing keys. Fix: Add *.keystore and *.jks files to .gitignore. Generate debug keystores locally and document the process in README. Never commit production keystores.
• Medium · Potential SQL Injection Risk in ORM Module — xutils/src/main/java/org/xutils/DbManager.java and related database classes. The codebase includes an ORM (Object-Relational Mapping) module (xutils/src/main/java/org/xutils/DbManager.java). Without reviewing the actual implementation, ORM modules commonly have SQL injection vulnerabilities if user input is not properly parameterized. Fix: Audit all database query methods to ensure parameterized queries are used. Review the implementation of the ORM to verify that all user input is properly escaped and that prepared statements are used exclusively.
• Medium · HTTP Module Security Considerations — xutils/src/main/java/org/xutils/HttpManager.java. The HTTP module supports both HTTP and HTTPS. Without reviewing implementation details, there's risk of insecure certificate validation, missing certificate pinning, or allowing HTTP fallback in sensitive contexts. Fix: Implement certificate pinning for sensitive endpoints. Verify that SSL/TLS validation is enabled by default. Audit network security configuration in AndroidManifest.xml. Ensure HTTPS is enforced for sensitive operations.
• Low · Missing Security Policy Documentation — README.md and root directory. No visible security policy, vulnerability disclosure policy, or security guidelines are documented in the README or repository. Fix: Add a SECURITY.md file with vulnerability reporting guidelines and security best practices. Document known limitations and security considerations for each module.
• Low · No Dependency Vulnerability Scanning — build.gradle configuration. The project does not appear to use automated dependency vulnerability scanning tools (OWASP Dependency-Check, Snyk, etc.), making it difficult to identify vulnerable transitive dependencies. Fix: Integrate dependency scanning tools. Add 'org.owasp.dependencycheck' plugin or use Snyk/Dependabot to automatically detect vulnerable dependencies.

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.