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/seven332/EhViewer shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 7y ago

• 4 active contributors
• Apache-2.0 licensed
• ⚠ Stale — last commit 7y ago
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 86% of recent commits
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live seven332/EhViewer repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/seven332/EhViewer.

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "seven332/EhViewer(\\.git)?\\b" \\
  && ok "origin remote is seven332/EhViewer" \\
  || miss "origin remote is not seven332/EhViewer (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/hippo/ehviewer/EhApplication.java" \\
  && ok "app/src/main/java/com/hippo/ehviewer/EhApplication.java" \\
  || miss "missing critical file: app/src/main/java/com/hippo/ehviewer/EhApplication.java"
test -f "app/src/main/java/com/hippo/ehviewer/client/EhClient.java" \\
  && ok "app/src/main/java/com/hippo/ehviewer/client/EhClient.java" \\
  || miss "missing critical file: app/src/main/java/com/hippo/ehviewer/client/EhClient.java"
test -f "app/src/main/java/com/hippo/ehviewer/client/EhEngine.java" \\
  && ok "app/src/main/java/com/hippo/ehviewer/client/EhEngine.java" \\
  || miss "missing critical file: app/src/main/java/com/hippo/ehviewer/client/EhEngine.java"
test -f "app/src/main/java/com/hippo/ehviewer/EhDB.java" \\
  && ok "app/src/main/java/com/hippo/ehviewer/EhDB.java" \\
  || miss "missing critical file: app/src/main/java/com/hippo/ehviewer/EhDB.java"
test -f "app/src/main/java/com/hippo/ehviewer/Settings.java" \\
  && ok "app/src/main/java/com/hippo/ehviewer/Settings.java" \\
  || miss "missing critical file: app/src/main/java/com/hippo/ehviewer/Settings.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 2494 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2464d)"
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/seven332/EhViewer"
  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).

EhViewer is a deprecated Android browser application for browsing E-Hentai galleries, built with Java and targeting Android API 14–28. It provides gallery parsing, image downloading, and caching via greenDAO ORM, jsoup HTML parsing, and OkHttp networking. The app was the primary Android client for accessing E-Hentai content with offline viewing capabilities. Monolithic Android app structure: app/src/main/java/com/hippo/ contains core logic, app/src/main/java-gen/ holds greenDAO-generated database classes, app/src/main/assets/ stores HTML assets (NOTICE.html). Debug and release flavors in app/src/debug and app/src/main with separate manifests and localized string resources (zh, es, ja, ko, fr, de, th).

Android users in regions with access to E-Hentai who wanted a mobile client with offline gallery support. Contributors were primarily the original author (Hippo Seven) and occasional community members; the project is explicitly marked deprecated and no longer maintained.

Deprecated as of 2019 (v1.7.3, versionCode 104). The codebase is mature in structure (2M+ lines Java, proper Gradle build, multi-language i18n) but abandoned—no recent commits visible, no active CI/CD, sparse test suite (only 4 test files in androidTest). Production code exists but should not be deployed to modern Android versions (targetSdkVersion 28 is from 2018).

High risk for new development: targets obsolete Android API levels (minSdkVersion 14 from 2011), depends on deprecated greenDAO, jsoup, and OkHttp versions likely unpached for modern security issues. Single maintainer (Hippo Seven), archived state means no security updates. E-Hentai's terms and blocking make this legally risky in many jurisdictions.

Nothing. The repository is archived and deprecated. The last version released was 1.7.3 (versionCode 104) in 2019. No ongoing development, PRs, or issues are being addressed.

git clone https://github.com/seven332/EhViewer
cd EhViewer
./gradlew app:assembleDebug

Generated APK will be in app/build/outputs/apk/. Requires JDK 8+ (source/target compatibility set to VERSION_1_8) and Android SDK 28.

Daily commands: Build variant: ./gradlew app:assembleDebug produces debug APK in app/build/outputs/apk/. Install with adb install or run emulator. No gradle test task visible for unit tests (minimal test coverage in androidTest/). No live dev server—this is a compiled Android app.

• app/src/main/java/com/hippo/ehviewer/EhApplication.java — Application entry point and global initialization; manages lifecycle and core dependencies for the entire E-Hentai client
• app/src/main/java/com/hippo/ehviewer/client/EhClient.java — Primary HTTP client interface for all E-Hentai API communication; handles authentication, request building, and response parsing
• app/src/main/java/com/hippo/ehviewer/client/EhEngine.java — Core business logic for parsing E-Hentai HTML responses and extracting gallery/search data; critical for content fetching
• app/src/main/java/com/hippo/ehviewer/EhDB.java — Central database access layer using greenDAO; manages all persistent storage for galleries, history, favorites, and user preferences
• app/src/main/java/com/hippo/ehviewer/Settings.java — Centralized configuration and preferences management; controls app-wide behavior, network settings, and UI preferences
• app/src/main/java/com/hippo/ehviewer/client/EhCookieStore.java — Persistent cookie storage and session management; essential for maintaining E-Hentai authentication state across app restarts
• app/build.gradle — Gradle build configuration; defines all dependencies, SDK versions, and build variants required to compile the application

Add a new search filter or tag category

1. Define new filter logic in the data model and add filter parameters (app/src/main/java/com/hippo/ehviewer/client/data/GalleryInfo.java)
2. Add parsing logic for the new filter in the engine (app/src/main/java/com/hippo/ehviewer/client/EhEngine.java)
3. Implement filter application in EhFilter class (app/src/main/java/com/hippo/ehviewer/client/EhFilter.java)
4. Add UI controls to settings or search activity to expose the new filter option

Add a new app setting or user preference

1. Define the new preference key and default value in the Settings class (app/src/main/java/com/hippo/ehviewer/Settings.java)
2. Add getter and setter methods following the existing pattern (app/src/main/java/com/hippo/ehviewer/Settings.java)
3. Create preference UI elements in the appropriate preference XML fragment (app/src/debug/res/values/strings.xml)
4. Hook the setting into the relevant business logic (e.g., EhClient, Eh

greenDAO code generation: daogenerator:executeDaoGenerator task runs during compile; modifying DB schema requires re-running this, not just editing Java. File provider authority: different for debug (com.hippo.ehviewer.debug.fileprovider) vs release—breaking file share intents if not respected. Ancient API target: minSdkVersion 14 (Android 4.0, 2011) makes modern APIs unavailable; maxSdkVersion not set, so Play Store distribution risky. Cookie persistence: CookieDBTest hints at custom cookie jar, likely not using OkHttp's built-in; check if E-Hentai session tokens persist correctly. No CI/CD visible: no .github/workflows or Travis config, so builds not tested on merge.

• greenDAO ORM and Code Generation — EhViewer uses greenDAO for SQLite persistence and generates DAO classes at build time (daogenerator:executeDaoGenerator task); understanding this is essential to modify database models without breaking queries.
• Android File Provider Authority — The app uses different file provider authorities for debug (com.hippo.ehviewer.debug.fileprovider) vs release—critical for file sharing intents and content URIs without exposing private directories.
• HTML Scraping with jsoup — Gallery data is extracted from E-Hentai HTML pages via jsoup selectors; understanding CSS selectors and jsoup's DOM API is needed to parse gallery metadata and image URLs.
• OkHttp Cookie Persistence & Session Management — E-Hentai requires login cookies; EhViewer uses a custom cookie jar (hinted by CookieDBTest.java) to maintain session state across app restarts, different from OkHttp's default in-memory jar.
• Android Build Variants (Debug vs Release) — EhViewer defines separate applicationId, file provider authority, and resource configs for debug vs release builds in build.gradle; critical to understand flavor-specific code paths.
• Native Image Codecs (libjpeg-turbo, libpng, giflib, apng) — Custom native libraries handle JPEG, PNG, GIF, and APNG decoding for gallery images, suggesting custom image rendering beyond Android's standard ImageView.
• Android API Level Compatibility & MinSDK Strategy — EhViewer targets minSdkVersion 14 (2011) and compileSdkVersion 28 (2018), requiring careful use of compatibility libraries and avoiding modern APIs; critical for understanding legacy code patterns.

• mokee/MoeGoe — Another Android manga/hentai browser alternative with similar OkHttp + jsoup stack and offline caching.
• isobelinc/Comics — Comics reader for Android with local gallery parsing and image caching, shares UI patterns with EhViewer.
• greenrobot/greenDAO — The ORM library EhViewer depends on; understand greenDAO mapping and code generation to modify app DB schema.
• jhy/jsoup — The HTML parser used for scraping E-Hentai gallery pages; crucial for understanding data extraction logic.
• square/okhttp — HTTP client underpinning all E-Hentai API requests and image downloads; essential for debugging network issues or cookie handling.

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

Add instrumented tests for database layer (CookieDBTest expansion)

The repo has minimal androidTest coverage with only CookieDBTest.java present. The MSQLiteBuilder and MSQLiteOpenHelper classes in app/src/main/java/com/hippo/database lack corresponding test files. Given this is a content-heavy app that likely manages significant database operations for galleries and user data, expanding database tests would catch regressions early.

• [ ] Expand app/src/androidTest/java/com/hippo/ehviewer/CookieDBTest.java with additional test cases for cookie persistence
• [ ] Create app/src/androidTest/java/com/hippo/ehviewer/DatabaseTest.java to test MSQLiteBuilder and MSQLiteOpenHelper functionality
• [ ] Add tests for database migration scenarios and schema integrity
• [ ] Run tests with ./gradlew app:connectedAndroidTest and document expected behavior

Add GitHub Actions CI workflow for Android builds and tests

The .github/ISSUE_TEMPLATE directory exists but there is no .github/workflows directory for CI/CD. The repo has build configuration (build.gradle, proguard-rules.pro) but no automated build verification on PRs. This means contributors can submit broken builds that aren't caught until merge.

• [ ] Create .github/workflows/android-build.yml to run ./gradlew app:assembleDebug app:assembleRelease on every PR
• [ ] Add lint checks: ./gradlew lint to validate code style compliance per lintOptions in build.gradle
• [ ] Include androidTest execution: ./gradlew app:connectedAndroidTest for emulator/device testing if feasible
• [ ] Document expected SDK versions and NDK setup needed for builds with abiFilters (armeabi-v7a, x86)

Complete missing localization strings documentation and add missing language configs

The build.gradle specifies 8 languages (zh, zh-rCN, zh-rHK, zh-rTW, es, ja, ko, fr, de, th) via resConfigs, but README only mentions Chinese and English. The debug resources show values-es, values-ja, values-ko, values-zh-* directories but the main source structure is incomplete. Contributors need guidance on which languages are actually maintained.

• [ ] Audit app/src/main/res/ directory structure to list which language values folders exist vs. which are declared in build.gradle
• [ ] Create docs/LOCALIZATION.md documenting: which languages are currently maintained, translation status per language, and how to add new language support
• [ ] If any declared languages lack corresponding main/res/values-XX folders, either remove them from resConfigs or create skeleton translation files
• [ ] Reference the existing app/src/debug/res/values-* examples to ensure consistency in main resources

• Add unit tests for the gallery parser (likely in a parser package under main/java)—currently only 4 test files exist (ApplicationTest, CardBgTest, CookieDBTest, DumpTest) with no gallery parsing coverage. Create a test case that mocks jsoup HTML and validates gallery metadata extraction.
• Update deprecated greenDAO library in build.gradle and regenerate DAO classes—greenDAO is no longer maintained; switch to Room ORM (AndroidX standard) to modernize the persistence layer. This involves refactoring app/src/main/java-gen/ and the daogenerator module.
• Add missing translations for the 10 supported languages (strings.xml exists only for some locales in app/src/debug/res/values-*/)—check app/src/main/res/ for the base translations and fill gaps in es, ja, ko, fr, de, th via community crowdsourcing or automated tools.

• High · Outdated Android SDK and Dependencies — app/build.gradle - compileSdkVersion 28, minSdkVersion 14, targetSdkVersion 28. The application targets Android SDK 28 (released in 2019) with compileSdkVersion 28. This is significantly outdated and missing critical security patches from newer Android versions. The minSdkVersion 14 (Android 4.0, released 2011) is extremely old and no longer receives security updates. Fix: Update compileSdkVersion and targetSdkVersion to at least 33 or higher (current is 34). Update minSdkVersion to at least 21 to ensure modern Android security features. Review and update all dependencies to their latest versions.
• High · Incomplete Dependency List in build.gradle — app/build.gradle - dependencies section. The build.gradle file is truncated and incomplete. The Material Design dependency declaration is cut off mid-string ('com.google.android.material:material:1.0 without closing quote). This prevents accurate vulnerability assessment of all dependencies used in the project. Fix: Provide the complete build.gradle file with all dependencies listed. Ensure all dependencies are properly formatted and version numbers are specified. Run 'gradle dependencyCheck' or use OWASP Dependency-Check to identify vulnerable dependencies.
• High · Disabled ProGuard Minification in Release Build — app/build.gradle - buildTypes.release section. The release build configuration has 'minifyEnabled false', meaning ProGuard obfuscation is disabled. This exposes the application logic to reverse engineering attacks, making it easier for attackers to analyze the app, find vulnerabilities, and potentially extract sensitive information. Fix: Enable minifyEnabled true and ensure proper ProGuard rules are configured in proguard-rules.pro. Test thoroughly after enabling to ensure app functionality is preserved.
• Medium · Deprecated Application Status — README.md - heading '# DEPRECATED'. The repository is marked as DEPRECATED in the README. This indicates the project is no longer actively maintained. Using deprecated applications poses security risks as vulnerabilities will not be patched. Fix: Consider using actively maintained alternatives. If continuing to use this codebase, conduct a comprehensive security audit and implement security patches independently.
• Medium · Conditional Gradle Plugin Application — app/build.gradle - conditional apply plugin statements. Google Services and Fabric plugins are conditionally applied based on the existence of 'google-services.json'. This creates inconsistent build configurations and could allow an attacker to disable Firebase/Crashlytics by removing this file, potentially preventing crash reporting and analytics. Fix: Always apply security and monitoring plugins consistently across all builds. If google-services.json is required, fail the build if it's missing rather than silently skipping the plugin.
• Medium · Missing Content Security Policies — app/src/main/java/com/hippo/ehviewer/ - entire package. No evidence of security configurations for data protection, encryption, or secure storage mechanisms in the analyzed files. The application appears to handle user data but no clear security measures are visible. Fix: Implement encrypted shared preferences for sensitive data storage, use HTTPS for all network communications, implement certificate pinning, and use Android Keystore for key management.
• Medium · Database Security Concerns — app/src/main/java/com/hippo/database/. The project includes custom SQLite database implementations (MSQLiteOpenHelper, MSQLiteBuilder) but without visible code review, there's a risk of SQL injection vulnerabilities, especially if user input is used in queries. Fix: Review all database code for parameterized queries. Ensure all user input is sanitized and use PreparedStatements. Consider using Room ORM which provides built-in protection against SQL injection.
• Low · Limited Architecture Support — app/build.gradle - ndk.abiFilters. The app only supports 'armeabi-v7a' and 'x86' ABIs. This excludes arm64-v8a (64-bit ARM), which is increasingly required by Google Play Store and provides better security features. Fix: Add 'arm64-v8a' to abiFilters to support 64-bit devices. Google Play now requires 64-bit support

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.