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/getActivity/AndroidProject 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 — Single-maintainer risk — review before adopting

• Last commit 1w ago
• 2 active contributors
• Apache-2.0 licensed
• CI configured
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 96% of recent commits
• ⚠ 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 getActivity/AndroidProject repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/getActivity/AndroidProject.

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "getActivity/AndroidProject(\\.git)?\\b" \\
  && ok "origin remote is getActivity/AndroidProject" \\
  || miss "origin remote is not getActivity/AndroidProject (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 "app/src/main/java/com/hjq/demo/app/AppApplication.java" \\
  && ok "app/src/main/java/com/hjq/demo/app/AppApplication.java" \\
  || miss "missing critical file: app/src/main/java/com/hjq/demo/app/AppApplication.java"
test -f "app/src/main/java/com/hjq/demo/http/model/RequestServer.java" \\
  && ok "app/src/main/java/com/hjq/demo/http/model/RequestServer.java" \\
  || miss "missing critical file: app/src/main/java/com/hjq/demo/http/model/RequestServer.java"
test -f "app/src/main/java/com/hjq/demo/app/AppActivity.java" \\
  && ok "app/src/main/java/com/hjq/demo/app/AppActivity.java" \\
  || miss "missing critical file: app/src/main/java/com/hjq/demo/app/AppActivity.java"
test -f "app/build.gradle" \\
  && ok "app/build.gradle" \\
  || miss "missing critical file: app/build.gradle"
test -f "app/src/main/java/com/hjq/demo/manager/InitManager.java" \\
  && ok "app/src/main/java/com/hjq/demo/manager/InitManager.java" \\
  || miss "missing critical file: app/src/main/java/com/hjq/demo/manager/InitManager.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 37 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~7d)"
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/getActivity/AndroidProject"
  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).

AndroidProject is a 7-year-old, battle-tested Android application architecture template that provides a complete technical foundation for building Android apps. It includes pre-built solutions for networking (HTTP APIs in app/src/main/java/com/hjq/demo/http/api/), AOP-based cross-cutting concerns (CheckNet, SingleClick, Log annotations in app/src/main/java/com/hjq/demo/aop/), UI components (Activities, Fragments, Adapters), and immersion/status bar handling, reducing new project setup time by roughly 50% while maintaining production-quality standards. Monolithic Android app module (app/) with layered structure: app/src/main/java/com/hjq/demo/ contains action handlers (action/), AOP interceptors (aop/), base classes (app/), and HTTP API definitions (http/api/). Uses gradle-based build configuration with namespace com.hjq.demo, build types for debug/release, and ProGuard obfuscation. Resources are split into res/ and res-common/ to share across buildVariants.

Android engineers and teams building commercial apps who want to skip boilerplate scaffolding and avoid reinventing the wheel for authentication (LoginApi, RegisterApi, PasswordApi), permission handling, HTTP interceptors, and common UI patterns. Specifically targets developers tired of copy-pasting legacy project code and seeking a maintained, documented reference architecture.

Highly mature and production-ready. The project has 7+ years of active maintenance, is deployed in multiple commercial projects, includes extensive optimization (memory, layout, code, binary), follows Android SDK source code conventions, and has a published APK for testing. CI/CD is configured (.github/workflows/android.yml) with GitHub Actions. However, last visible activity and star count are not in the provided data; recommend checking the GitHub repo directly for current momentum.

Low risk for established projects, but moderate single-maintainer dependency (appears to be driven by one lead engineer, getActivity). The codebase is stable and battle-tested, but contributions depend heavily on the maintainer's availability. Build configuration relies on external gradle properties (STORE_FILE, HOST_URL, BUGLY_ID) that must be correctly supplied. No visible test suite in the file listing, which is a gap for a template project claiming production-grade quality.

The provided file list does not include recent commit history or open PRs. However, the repository mentions version 13.1 (AndroidProject.apk), suggesting active version management. The codebase is in maintenance mode with incremental optimizations rather than major feature development. Check GitHub releases and commits directly for current activity.

1. Clone: git clone https://github.com/getActivity/AndroidProject.git 2. Navigate: cd AndroidProject 3. Open in Android Studio and sync Gradle (Gradle wrapper is configured via gradle plugins alias). 4. Create or update gradle.properties with required build config (LOG_ENABLE, HOST_URL, BUGLY_ID, BUGLY_KEY, signing config). 5. Build: ./gradlew assembleDebug or ./gradlew assembleRelease.

Daily commands:

1. ./gradlew assembleDebug to build debug APK. 2. ./gradlew installDebug to deploy to connected device/emulator. 3. Or open in Android Studio and click Run. Launch app to see demo UI screens (36 activity screenshots, 18 dialog screenshots documented in README). For Kotlin variant: switch to https://github.com/getActivity/AndroidProject-Kotlin.

• app/src/main/java/com/hjq/demo/app/AppApplication.java — Application entry point; initializes all framework components, managers, and crash handling — must understand this to grasp the app's initialization flow
• app/src/main/java/com/hjq/demo/http/model/RequestServer.java — HTTP client configuration and interceptor setup; core to understanding API request handling and authentication flow
• app/src/main/java/com/hjq/demo/app/AppActivity.java — Base activity class providing common lifecycle behavior, status bar management, and fragment handling — foundation for all UI components
• app/build.gradle — Build configuration and dependency declarations; essential for understanding the project's library ecosystem and build setup
• app/src/main/java/com/hjq/demo/manager/InitManager.java — Manages runtime initialization of subsystems; controls the order and configuration of framework startup
• app/src/main/java/com/hjq/demo/other/AppConfig.java — Centralized configuration constants and feature flags; defines app-wide behavior and environment settings
• app/src/main/java/com/hjq/demo/http/model/RequestHandler.java — Request/response interceptor logic and error handling; critical for understanding API communication patterns and exception handling

Add a New API Endpoint

1. Create a new API interface in app/src/main/java/com/hjq/demo/http/api/ (e.g., NewApi.java) extending the API pattern, declaring the HTTP method and endpoint path (app/src/main/java/com/hjq/demo/http/api/LoginApi.java)
2. Define the request/response data classes (POJO) in the http/model/ directory, ensuring they match the server contract (app/src/main/java/com/hjq/demo/http/model/HttpData.java)
3. Use RequestServer.getInstance().getApi(NewApi.class).methodName() in your Activity/Fragment to invoke the endpoint; RequestHandler automatically applies interceptors, caching, and error handling (app/src/main/java/com/hjq/demo/http/model/RequestServer.java)
4. Handle exceptions (ResultException, TokenException) in your callback or observe pattern; CrashHandler logs unhandled exceptions (app/src/main/java/com/hjq/demo/http/exception/ResultException.java)

Add a New UI Screen (Activity)

1. Create a new Activity class extending AppActivity in the appropriate feature package under app/src/main/java/com/hjq/demo/ui/activity/ (app/src/main/java/com/hjq/demo/app/AppActivity.java)
2. Override initView() to inflate layout and initialize UI components; AppActivity automatically handles status bar, immersion, and title bar setup (app/src/main/java/com/hjq/demo/ui/activity/HomeActivity.java)
3. Override initData() to fetch data via API calls using RequestServer; optionally apply @CheckNet and @SingleClick AOP annotations to methods (app/src/main/java/com/hjq/demo/aop/CheckNetCut.java)
4. Declare the Activity in AndroidManifest.xml; register in app/src/main/java/com/hjq/demo/app/AppAdapter.java if it belongs to a navigation menu (app/src/main/AndroidManifest.xml)

Implement AOP Interceptor (Cross-Cutting Concern)

1. Create an annotation interface in app/src/main/java/com/hjq/demo/aop/ (e.g., @NewAspect) following the pattern of @SingleClick or @CheckNet (app/src/main/java/com/hjq/demo/aop/SingleClick.java)
2. Create the corresponding Cut class (NewAspectCut.java) implementing the weaving logic that intercepts annotated methods at compile time (app/src/main/java/com/hjq/demo/aop/SingleClickCut.java)
3. Register the Cut class in build.gradle under the aop plugin configuration, or ensure it is auto-discovered by the plugin (app/build.gradle)
4. Annotate target methods in Activities, Fragments, or API classes with @NewAspect; the AOP framework will inject the interceptor bytecode at compile time (app/src/main/java/com/hjq/demo/ui/activity/HomeActivity.java)

Customize Permission Requests

1. Define or extend permission descriptions in app/src/main/java/com/hjq/demo/permission/PermissionDescription.java with user-friendly strings for each permission (app/src/main/java/com/hjq/demo/permission/PermissionDescription.java)
2. Update PermissionConverter.java to map new permissions to description constants if custom conversion logic is needed (app/src/main/java/com/hjq/demo/permission/PermissionConverter.java)
3. In your Activity/Fragment, use PermissionInterceptor or the framework's permission request flow to prompt users; the framework shows the rationale dialog automatically (app/src/main/java/com/hjq/demo/permission/PermissionInterceptor.java)

1. Build properties required: app/gradle.properties must define LOG_ENABLE, HOST_URL, BUGLY_ID, BUGLY_KEY, and signing credentials (STORE_FILE, STORE_PASSWORD, KEY_ALIAS, KEY_PASSWORD); build will fail silently or with cryptic errors if missing. 2. Resource filtering: Only Chinese (zh) resources and xxhdpi image density are retained by default (resConfigs 'zh', 'xxhdpi'); adding other languages/densities requires modifying defaultConfig. 3. Architecture constraint: Only arm64-v8a is configured; 32-bit devices and other architectures are unsupported (explicit in gradle; MMKV 2.0+ doesn't support 32-bit). 4. AOP requires annotation processor: The aop plugin (alias plugins.aop) must be enabled and may require additional config not visible in snippet; verify plugin-aop is included in Gradle dependencies. 5. Package namespace: applicationId 'com.hjq.demo' is hardcoded; renaming requires changes in multiple places (README mentions painless rename but actual steps not provided in file list).

• Aspect-Oriented Programming (AOP) — Core framework mechanism in this repo (CheckNet, SingleClick, Log annotations); essential for understanding how cross-cutting concerns like network checks and click throttling are applied without cluttering business logic
• Annotation Processing (Java Compile-Time) — AOP implementation relies on annotation processors (alias plugins.aop in gradle); understanding compile-time vs. runtime annotation handling is critical for extending the AOP system safely
• ProGuard / R8 Obfuscation — Project explicitly optimizes binary size and security via proguard-app.pro and proguard-sdk.pro; understanding obfuscation rules prevents runtime crashes from reflection-dependent libraries
• Gradle Plugin Architecture — Build is driven by gradle plugins (kotlin, aop, easyLauncher) via plugin aliases; understanding plugin hooks is necessary for customizing build variants and CI/CD
• Android Activity / Fragment Lifecycle — Base classes AppActivity and AppFragment encapsulate lifecycle hooks and common state management; misunderstanding lifecycle leads to memory leaks and crashes in this architecture
• Immersion/Edge-to-Edge UI Pattern — ImmersionAction.java handles status bar and navigation bar integration; modern Android requires this pattern for full-screen and gesture navigation support
• Resource Configuration Qualifiers — Project filters resources to 'zh' (Chinese only) and 'xxhdpi' density via resConfigs; understanding qualifier strategy is crucial for adding multi-language or multi-device support without bloating the APK

• getActivity/AndroidProject-Kotlin — Official Kotlin variant of this same architecture; directly paired codebase for teams preferring Kotlin over Java
• alibaba/AAPPT — Alibaba's Android architectural reference; complements this project with additional patterns and best practices from another major Android architecture effort
• google/architecture-samples — Google's official Android app architecture samples (MVI/MVVM); useful comparison of modern Google-endorsed patterns vs. getActivity's MVC/MVP foundation
• JakeWharton/timber — Widely-used logging library for Android; likely integrated into AndroidProject's Log AOP and useful for understanding the logging cross-cutting concern
• square/retrofit — De facto standard HTTP client for Android; HTTP API classes in http/api/ almost certainly use Retrofit under the hood

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 HTTP exception handling (ResultException.java and TokenException.java)

The repo has custom exception classes in app/src/main/java/com/hjq/demo/http/exception/ but there are no corresponding unit tests. These exceptions are critical to the HTTP request flow and error handling strategy. Adding tests would ensure proper exception behavior, improve code coverage, and make the architecture more maintainable as the codebase evolves.

• [ ] Create app/src/test/java/com/hjq/demo/http/exception/ directory structure
• [ ] Add ResultExceptionTest.java to test exception instantiation, message handling, and error code extraction
• [ ] Add TokenExceptionTest.java to verify token-related exception scenarios and recovery flows
• [ ] Add tests for RequestHandler.java to verify how exceptions are caught and processed
• [ ] Integrate tests into the existing GitHub Actions workflow (.github/workflows/android.yml)

Add unit tests for HttpCacheManager and HttpCacheStrategy (app/src/main/java/com/hjq/demo/http/model/)

The caching system (HttpCacheManager.java and HttpCacheStrategy.java) is a core feature but lacks test coverage. This is especially important since caching directly impacts app performance and data consistency. Tests would validate cache hit/miss scenarios, eviction policies, and strategy selection logic.

• [ ] Create app/src/test/java/com/hjq/demo/http/model/cache/ directory
• [ ] Add HttpCacheManagerTest.java testing cache put/get operations, expiration, and capacity limits
• [ ] Add HttpCacheStrategyTest.java testing different cache strategy implementations and selection logic
• [ ] Add integration tests for RequestHandler.java verifying cache interaction with HTTP requests
• [ ] Add MockInterceptor to simulate network responses for cache testing

Expand AOP aspect test coverage (app/src/main/java/com/hjq/demo/aop/)

The repo implements several AOP aspects (SingleClickCut.java, CheckNetCut.java, LogCut.java) which are instrumentation-heavy features but appear to lack automated testing. These aspects are critical to preventing user errors and logging behavior. Adding instrumentation tests would verify annotation processing, method interception, and side effects.

• [ ] Create app/src/androidTest/java/com/hjq/demo/aop/ directory for instrumentation tests
• [ ] Add SingleClickCutTest.java to verify rapid click prevention and time window enforcement
• [ ] Add CheckNetCutTest.java to mock network states and verify network availability checks
• [ ] Add LogCutTest.java to verify log output, log levels, and method parameter logging
• [ ] Create a test Activity that applies all aspects to verify runtime weaving behavior

• Add unit tests for API classes: File list shows 9 HTTP API classes (LoginApi.java, RegisterApi.java, etc.) but no visible test directory; contributing test cases for successful/error responses would improve template reliability for new projects
• Document AOP annotation usage with examples: aop/ folder has CheckNet, SingleClick, Log annotations but unclear how to apply them; adding JavaDoc comments and example usage to CheckNetCut.java, SingleClickCut.java would reduce onboarding friction
• Create configuration template file (gradle.properties.template): gradle.properties with HOST_URL, BUGLY_ID, signing credentials is required but .gitignored; providing a .template file with placeholders and inline comments would prevent build-time confusion for new contributors
• Add Kotlin interop examples: Separate Kotlin variant repo exists (AndroidProject-Kotlin) but main repo is Java-only; adding sample Kotlin Activity/Fragment alongside Java equivalents would help teams adopting mixed-language projects
• Expand ProGuard rules documentation: proguard-app.pro and proguard-sdk.pro are included but not commented; adding inline explanations for rule choices (especially around reflection-heavy libraries) would help maintainers avoid ProGuard-related crashes

• High · Keystore Credentials Exposed in Repository — app/AppSignature.jks. The file 'app/AppSignature.jks' (Android keystore file) is present in the repository. Keystore files contain sensitive signing credentials that should never be committed to version control, as they can be used to sign malicious APKs impersonating the legitimate application. Fix: Immediately revoke this keystore and generate a new one. Add AppSignature.jks to .gitignore. Store the keystore securely outside the repository (e.g., in CI/CD secrets or a secure artifact repository). Consider rotating signing keys if this repository is public.
• High · BuildConfig Contains Hardcoded Configuration Values — app/build.gradle (buildConfigField configuration). The build.gradle file contains hardcoded configuration for sensitive values like BUGLY_ID, BUGLY_KEY, HOST_URL, LOG_ENABLE, and keystore passwords injected via buildConfigField. These values are embedded in the compiled APK and can be reverse-engineered. Credentials like BUGLY_KEY should never be hardcoded. Fix: Move sensitive configuration to external secure sources: (1) Use gradle.properties with .gitignore protection for local development, (2) Implement server-side configuration for production endpoints, (3) Store API keys in CI/CD environment variables, (4) Use Android KeyStore for runtime credential storage, (5) Consider using a secure configuration management solution.
• High · Potential Keystore Credentials in gradle.properties — app/gradle.properties and app/build.gradle (signingConfigs block). The build configuration references STORE_FILE, STORE_PASSWORD, KEY_ALIAS, and KEY_PASSWORD variables from gradle.properties (referenced in signingConfigs). If these are hardcoded in the committed gradle.properties file, they represent exposed keystore credentials. Fix: Ensure gradle.properties containing sensitive credentials is in .gitignore. Use local gradle.properties (not committed) for development. Implement secure credential injection in CI/CD pipelines using environment variables or secret management systems. Never commit keystore passwords.
• Medium · Debug Mode Enabled in Debug Build Type — app/build.gradle (buildTypes.debug section). The build configuration enables debuggable=true and jniDebuggable=true for debug builds. While appropriate for development, ensure this is explicitly disabled in release builds to prevent attackers from attaching debuggers to production applications. Fix: Verify that debuggable=false and jniDebuggable=false are explicitly set in the release buildType. Implement automated checks to prevent accidental release builds with debugging enabled. Add ProGuard/R8 obfuscation rules to production builds.
• Medium · ProGuard Configuration Files Present — app/proguard-sdk.pro, app/proguard-app.pro. ProGuard configuration files (proguard-sdk.pro, proguard-app.pro) are present. Without reviewing their content, it's unclear if they provide adequate obfuscation for sensitive code paths, API endpoints, and credentials. Fix: Review ProGuard rules to ensure: (1) All API classes and sensitive business logic are obfuscated, (2) String constants containing URLs or keys are not excluded, (3) Exception handling preserves security, (4) Consider using R8 for improved obfuscation and optimization, (5) Test obfuscated builds for functionality.
• Medium · HTTP API Implementation Without Visible Security Validation — app/src/main/java/com/hjq/demo/http/api/. Multiple HTTP API classes are present (LoginApi, RegisterApi, etc.) in the codebase. Without code review, it's unclear if these implement certificate pinning, proper SSL/TLS validation, or protection against man-in-the-middle attacks. Fix: Implement certificate pinning using OkHttp's CertificatePinner. Enforce HTTPS only. Validate server certificates properly. Implement request/response encryption where applicable. Add security headers (HSTS, etc.). Implement API rate limiting and request signing.
• Medium · Token Handling Exception Without Clear Token Validation — app/src/main/. TokenException class exists, suggesting token-based authentication. However, without code review, it's unclear if tokens are properly validated, have expiration checks, secure storage mechanisms, or protection against token theft. Fix: undefined

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.