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/JessYanCoding/MVPArms 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

• 12 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Concentrated ownership — top contributor handles 79% 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 JessYanCoding/MVPArms repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/JessYanCoding/MVPArms.

What it runs against: a local clone of JessYanCoding/MVPArms — 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 JessYanCoding/MVPArms | 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 ≤ 1173 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "JessYanCoding/MVPArms(\\.git)?\\b" \\
  && ok "origin remote is JessYanCoding/MVPArms" \\
  || miss "origin remote is not JessYanCoding/MVPArms (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 "arms/src/main/java/com/jess/arms/base/BaseActivity.java" \\
  && ok "arms/src/main/java/com/jess/arms/base/BaseActivity.java" \\
  || miss "missing critical file: arms/src/main/java/com/jess/arms/base/BaseActivity.java"
test -f "arms/src/main/java/com/jess/arms/base/BaseFragment.java" \\
  && ok "arms/src/main/java/com/jess/arms/base/BaseFragment.java" \\
  || miss "missing critical file: arms/src/main/java/com/jess/arms/base/BaseFragment.java"
test -f "arms/src/main/java/com/jess/arms/di/component/AppComponent.java" \\
  && ok "arms/src/main/java/com/jess/arms/di/component/AppComponent.java" \\
  || miss "missing critical file: arms/src/main/java/com/jess/arms/di/component/AppComponent.java"
test -f "arms/src/main/java/com/jess/arms/base/delegate/ActivityDelegateImpl.java" \\
  && ok "arms/src/main/java/com/jess/arms/base/delegate/ActivityDelegateImpl.java" \\
  || miss "missing critical file: arms/src/main/java/com/jess/arms/base/delegate/ActivityDelegateImpl.java"
test -f "arms/src/main/java/com/jess/arms/http/imageloader/ImageLoader.java" \\
  && ok "arms/src/main/java/com/jess/arms/http/imageloader/ImageLoader.java" \\
  || miss "missing critical file: arms/src/main/java/com/jess/arms/http/imageloader/ImageLoader.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 1173 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1143d)"
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/JessYanCoding/MVPArms"
  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).

MVPArms is a production-grade MVP (Model-View-Presenter) architecture framework for Android that integrates Dagger2, RxJava, and Retrofit to eliminate boilerplate and accelerate development. It provides pre-configured modules (arms-autolayout for responsive layouts, arms-imageloader-glide for image management) and an IDE template generator to scaffold MVP+Dagger2 classes automatically, allowing developers to focus on business logic rather than structural plumbing. Multi-module monorepo: core arms/ library contains the MVP base classes and DI scaffolding; specialized modules arms-autolayout/ (responsive widget wrappers for AppBarLayout, TabLayout, etc.) and arms-imageloader-glide/ (Glide wrapper with blur and cache strategies) provide optional extensions. The demo/ module serves as a reference implementation showing UserActivity MVP pattern with packages pre-structured for Controllers, Models, Services, and Dagger components.

Android developers building enterprise apps who need a battle-tested MVP architecture with dependency injection and reactive programming already wired in. Particularly useful for teams wanting to standardize project structure across multiple apps without rebuilding the DI/networking foundation each time.

Actively maintained and production-ready. Published to Jcenter as v2.5.2, supports API 14+, has CI via Travis, and includes extensive documentation (MVPArms.md in Chinese, wiki, and a companion template plugin for Android Studio). The codebase is 387K lines of Java and the project has attracted sufficient ecosystem (QQ groups with 455K+ members), though commit recency data is not visible in the provided snapshot.

Moderate-to-low risk for active projects. The framework tightly couples to specific dependency versions (Dagger2, RxJava, Retrofit, Glide) defined in root gradle.properties—upgrading those libraries requires careful coordination. Single-maintainer risk is present (JessYanCoding). The autolayout module has custom dimension resolution logic that may conflict with modern Material Design 3 adaptive layout systems. No test directory visible in the file list suggests limited test coverage.

The repo has active issue tracking (ISSUE_TEMPLATE.md present) and contribution guidelines (CONTRIBUTING.md, CONTRIBUTING_APP.md), suggesting ongoing maintenance. The MVPArms_generator_solution directory indicates work on tooling improvements. A companion project (MVPArms-Module-Template) was created to streamline new project scaffolding, showing the maintainer is addressing friction points in adoption.

git clone https://github.com/JessYanCoding/MVPArms.git
cd MVPArms
# Open in Android Studio or build via:
./gradlew build

Or use the new one-click module generator: clone MVPArms-Module-Template into Android Studio's plugins directory and generate a new app module directly. For existing projects, add the Jcenter dependency: implementation 'com.jess.ui:mvparms:2.5.2' (exact version in build.gradle files).

Daily commands: This is a library/framework project, not an executable app. To run the demo reference implementation: ./gradlew :demo:installDebug (requires Android device/emulator). To use in your own app, depend on the published artifact or include the arms module as a local dependency in settings.gradle and reference it in build.gradle: implementation project(':arms').

• arms/src/main/java/com/jess/arms/base/BaseActivity.java — Core MVP Activity base class that all screen-level components inherit from; defines lifecycle and presenter integration patterns.
• arms/src/main/java/com/jess/arms/base/BaseFragment.java — Core MVP Fragment base class handling presenter lifecycle and view delegation for modular screens.
• arms/src/main/java/com/jess/arms/di/component/AppComponent.java — Root Dagger2 component wiring all singletons and app-level dependencies; entry point for DI configuration.
• arms/src/main/java/com/jess/arms/base/delegate/ActivityDelegateImpl.java — Implements activity lifecycle delegation pattern, decoupling framework concerns from business logic.
• arms/src/main/java/com/jess/arms/http/imageloader/ImageLoader.java — Abstraction layer for pluggable image loading strategies (Glide); critical for media handling.
• arms/src/main/java/com/jess/arms/integration/ActivityLifecycle.java — Global activity lifecycle interceptor for cross-cutting concerns like logging and monitoring.
• arms/src/main/java/com/jess/arms/di/module/GlobalConfigModule.java — Centralized configuration module for HTTP clients, interceptors, and global handlers.

Create a New MVP Screen (Activity)

1. Create Contract interface defining View and Presenter interfaces (arms/src/main/java/com/jess/arms/base/BaseActivity.java)
2. Implement Presenter class handling business logic and lifecycle (arms/src/main/java/com/jess/arms/base/delegate/ActivityDelegateImpl.java)
3. Extend BaseActivity and bind presenter via DI with @ActivityScope (arms/src/main/java/com/jess/arms/di/scope/ActivityScope.java)
4. Create activity-level Dagger Module and Component injecting Presenter (arms/src/main/java/com/jess/arms/di/component/AppComponent.java)
5. Declare activity-scoped providers in custom module extending AppModule (arms/src/main/java/com/jess/arms/di/module/AppModule.java)

Add Global HTTP Interceptor or Error Handling

1. Implement GlobalHttpHandler interface for response/error callbacks (arms/src/main/java/com/jess/arms/http/GlobalHttpHandler.java)
2. Create custom OkHttpClient interceptor extending RequestInterceptor (arms/src/main/java/com/jess/arms/http/log/RequestInterceptor.java)
3. Register interceptor in GlobalConfigModule via ClientModule configuration (arms/src/main/java/com/jess/arms/di/module/GlobalConfigModule.java)
4. Pass handler to AppComponent via module binding (arms/src/main/java/com/jess/arms/di/component/AppComponent.java)

Implement Custom Image Loader Strategy

1. Extend BaseImageLoaderStrategy implementing load/clear/pause methods (arms/src/main/java/com/jess/arms/http/imageloader/BaseImageLoaderStrategy.java)
2. Create custom ImageConfig subclass for strategy-specific options (arms-imageloader-glide/src/main/java/com/jess/arms/http/imageloader/glide/ImageConfigImpl.java)
3. Register strategy in GlobalConfigModule as singleton provider (arms/src/main/java/com/jess/arms/di/module/GlobalConfigModule.java)
4. Inject ImageLoader in Views/Presenters via @Inject annotation (arms/src/main/java/com/jess/arms/http/imageloader/ImageLoader.java)

Add Lifecycle Hook for Application Startup

1. Implement AppLifecycles interface with attachBaseContext/onCreate/onTerminate (arms/src/main/java/com/jess/arms/base/delegate/AppLifecycles.java)
2. Register implementation in GlobalConfigModule as multi-binding (arms/src/main/java/com/jess/arms/di/module/GlobalConfigModule.java)
3. AppDelegate automatically invokes all registered lifecycle callbacks (arms/src/main/java/com/jess/arms/base/delegate/AppDelegate.java)

• MVP Pattern — Separates UI logic from business logic; enables testable, reusable presenters across activities/fragments; core architectural philosophy of the framework
• Dagger2 — undefined

Dimension conversion in autolayout: the Auto* widgets use a reference screen width/height (likely defined in attrs.xml or application metadata) to scale all dimension values—if your design uses a different base resolution, layouts will scale incorrectly. RxJava lifecycle: the framework likely auto-unsubscribes RxJava streams in onDestroy—manually holding subscriptions or using .subscribe() without attaching to lifecycle will cause memory leaks. Dagger component scoping: if you define custom component scopes without understanding lifecycle (Activity, Fragment, Application), you may create singletons that outlive their intended scope. Glide cache keys: the CacheStrategy may collide if you load the same URL with different transformation parameters—verify cache key composition. API level 14+ legacy code: the framework targets very old Android APIs; newer Java features (lambdas, streams) are not used, and AndroidX dependencies may conflict if you mix modern libraries.

• Model-View-Presenter (MVP) — The entire architectural foundation of this framework; you must understand the contract between View (UI callbacks), Presenter (business logic orchestration), and Model (data) to use MVPArms effectively.
• Dependency Injection via Dagger2 — MVPArms auto-generates Dagger components and modules; understanding scopes (Activity, Application, Custom) and how @Provides/@Inject work is mandatory to customize DI for new features.
• Reactive Streams (RxJava) — Retrofit responses in MVPArms are wrapped in Observables and Flowables; you must understand subscriptions, operators, and lifecycle binding to avoid memory leaks and handle backpressure.
• Android Layout Dimension Scaling — The arms-autolayout module performs proportional dimension scaling based on a reference screen size; misunderstanding this causes responsive layout failures and UI misalignment.
• Strategy Pattern for Image Loading — MVPArms encapsulates Glide behind an ImageLoaderStrategy interface; understanding this pattern lets you swap image loaders (Picasso, Coil) without changing app code.
• Retrofit Service Definitions — HTTP requests in MVPArms flow through Retrofit interfaces generated via annotations; you must know @GET/@POST, interceptors, and error handling to integrate APIs.
• Activity/Fragment Lifecycle Awareness in RxJava — MVPArms likely uses RxLifecycle or manual unsubscribe in onDestroy to prevent subscription memory leaks; understanding Android lifecycle is critical to avoid crashes and resource exhaustion.

• googlesamples/android-architecture — Official Google reference implementations of MVP, MVVM, and MVI on Android; useful to compare architecture patterns and see how Google approaches dependency injection and testing.
• chrisbanes/plaid — Production app showcasing Material Design and modern Android patterns; demonstrates real-world use of RxJava, Retrofit, and Dagger2 similar to MVPArms' stack.
• bumptech/glide — The underlying image loading library that arms-imageloader-glide wraps; essential for understanding cache behavior, transformations, and lifecycle integration.
• google/dagger — Dagger2 documentation and source; required to fully understand the dependency injection wiring that MVPArms automates in generated components.
• ReactiveX/RxJava — The reactive streams library core to MVPArms' asynchronous handling; essential for debugging subscription leaks and understanding backpressure in HTTP calls.

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 BaseActivity and BaseFragment lifecycle methods

The core MVP architecture relies on BaseActivity.java and BaseFragment.java for lifecycle management and presenter binding. Currently, there are no visible test files in the repository. Adding unit tests would verify that lifecycle hooks (onCreate, onDestroy, etc.) properly initialize/release presenters and prevent memory leaks—critical for an MVP framework.

• [ ] Create arms/src/test/java/com/jess/arms/base/BaseActivityTest.java with tests for presenter initialization and lifecycle callbacks
• [ ] Create arms/src/test/java/com/jess/arms/base/BaseFragmentTest.java testing lazy loading behavior in BaseLazyLoadFragment.java
• [ ] Add mock/instrumentation tests in arms/src/androidTest to verify View binding and presenter attachment during Activity/Fragment transitions
• [ ] Add test dependency configuration to arms/build.gradle for JUnit, Mockito, and AndroidX Test libraries

Add GitHub Actions CI workflow to replace Travis CI and test against multiple Android SDK versions

The repo uses .travis.yml for CI, but GitHub Actions is now the native CI/CD platform for GitHub. The project should maintain compatibility across API levels 14+ (as stated in README), but currently there's no visible matrix testing across SDK versions. A GitHub Actions workflow would modernize CI and validate the framework against minSdkVersion 14+ variants.

• [ ] Create .github/workflows/android-build.yml with matrix strategy testing against Android SDK versions 21, 29, 31, 33
• [ ] Configure gradle tasks to run ./gradlew build, lint, and proguard checks across all modules (arms, arms-autolayout, arms-imageloader-glide)
• [ ] Add workflow step to validate ProGuard rules in arms/proguard-rules.pro don't break public API surface
• [ ] Optional: Add GitHub Action to automatically post test results and code coverage to PRs

Document AutoLayout widget configuration and add missing AutoView variants for common widgets

The arms-autolayout module contains several Auto* widget implementations (AutoAppBarLayout, AutoToolbar, AutoTabLayout) but lacks documentation on how screen density adaptation works. Additionally, looking at the file structure, there are likely missing Auto* variants for common widgets like AutoFrameLayout, AutoLinearLayout, and AutoGridView that developers would expect to use alongside AutoCardView.

• [ ] Create arms-autolayout/AUTOLAYOUT_GUIDE.md documenting the screen density calculation formula, design reference resolution configuration, and usage examples
• [ ] Add missing AutoFrameLayout.java, AutoLinearLayout.java, and AutoGridView.java classes to arms-autolayout/src/main/java/com/jess/arms/widget/autolayout/ following the pattern of existing Auto* widgets
• [ ] Update arms-autolayout/src/main/res/values/attrs.xml to include custom attributes for newly added widgets
• [ ] Add code examples to README.md or MVPArms.md showing how to enable AutoLayout in a sample Activity layout

• Add unit tests for arms-imageloader-glide/src/main/java/com/jess/arms/http/imageloader/glide/BlurTransformation.java—currently no test file visible; write tests covering blur radius edge cases and null image handling.
• Document the exact dimension calculation formula in arms-autolayout/src/main/java/com/jess/arms/widget/autolayout/ classes with inline code comments and a README in arms-autolayout/ explaining how to measure and set the reference screen size for your design.
• Create a modern Jetpack Compose example module (e.g., arms-compose-demo/) showing how to integrate the framework's Dagger2 and Retrofit setup with Compose UIs, since the current demo uses only legacy Views.

The MVPAr

• High · Outdated and Potentially Vulnerable Dependencies — arms-autolayout/build.gradle, arms/build.gradle, dependency configuration. The project uses Material Design library (design), AppCompat, and other support libraries that are no longer actively maintained. The minimum SDK is API 14, suggesting this project may be using very old dependency versions. No dependency version constraints or lock files are visible in the provided gradle configuration. Fix: 1. Migrate from legacy support libraries to AndroidX. 2. Update all dependencies to their latest stable versions. 3. Implement a dependency management strategy with version pinning. 4. Use gradle dependency verification for supply chain security.
• High · ProGuard Configuration in Release Build — arms-autolayout/proguard-rules.pro, arms/proguard-rules.pro (not shown). The build configuration references 'proguard-rules.pro' files, but these are not visible in the provided file structure. If ProGuard rules are misconfigured or missing, sensitive code patterns, API endpoints, or class names could be exposed in the released APK. Fix: 1. Review and audit all ProGuard/R8 configuration files. 2. Ensure sensitive packages are properly obfuscated. 3. Test obfuscation with actual release builds. 4. Keep ProGuard configuration in version control and review during code reviews.
• Medium · Missing Security-Related Build Configuration — build.gradle files across modules. The build configuration does not show explicit security settings such as debuggable=false for release builds, security provider patches, or security-relevant manifest hardening options. Fix: 1. Explicitly set debuggable=false in release buildType. 2. Implement security provider updates using AndroidSecurityProvider. 3. Add manifest hardening options (usesCleartextTraffic=false). 4. Configure certificate pinning for network communications.
• Medium · No Visible Security Testing or Scanning — .travis.yml, CI/CD configuration. The .travis.yml file exists but content is not shown. There's no evidence of security scanning tools (OWASP Dependency-Check, Checkmarx, etc.) in the CI/CD pipeline. No security policies or vulnerability disclosure process is evident. Fix: 1. Integrate OWASP Dependency-Check into CI/CD pipeline. 2. Add static analysis tools (Lint, Find Bugs, Spotbugs). 3. Implement dynamic security testing. 4. Create a SECURITY.md file with vulnerability disclosure policy.
• Medium · Unsafe Dependency Exclusions — arms-autolayout/build.gradle (design, cardview, autolayout dependencies). The gradle configuration uses blanket module exclusions (e.g., excluding 'appcompat', 'legacy-support-v4') without clear justification. This could lead to version conflicts or missing security patches if transitive dependencies are not properly managed. Fix: 1. Document why each module is excluded. 2. Use gradle dependency constraint management instead of exclusions. 3. Perform conflict resolution analysis. 4. Keep excluded dependencies updated independently if needed.
• Low · Code of Conduct and Contributing Guidelines Present — CODE_OF_CONDUCT.md, CONTRIBUTING.md, CONTRIBUTING_APP.md. While CODE_OF_CONDUCT.md and CONTRIBUTING.md exist (positive sign), the security-related contribution guidelines are not visible. The CONTRIBUTING_APP.md file suggests app-specific contributions but security requirements are unclear. Fix: 1. Add security review requirements to CONTRIBUTING.md. 2. Establish code review guidelines focusing on security. 3. Create SECURITY.md with vulnerability reporting process. 4. Document secure coding standards for contributors.
• Low · Potential Information Disclosure in Build Artifacts — arms-autolayout/gradle.properties, arms/gradle.properties (and others). The project structure includes multiple gradle.properties files which could contain sensitive configuration. While none were provided for review, these files should be carefully managed. Fix: 1. Ensure gradle.properties never contains API keys, passwords, or tokens. 2. Use gradle.properties only for non-sensitive configuration. 3. Use gradle-vault or similar for secrets management. 4. Add gradle.properties patterns to .gitignore for local overrides.

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.