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/HotBitmapGG/bilibili-android-client 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 5y ago

• 2 active contributors
• WTFPL licensed
• Tests present
• ⚠ Stale — last commit 5y ago
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 99% of recent commits
• ⚠ Non-standard license (WTFPL) — 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 HotBitmapGG/bilibili-android-client repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/HotBitmapGG/bilibili-android-client.

What it runs against: a local clone of HotBitmapGG/bilibili-android-client — 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 HotBitmapGG/bilibili-android-client | Confirms the artifact applies here, not a fork | | 2 | License is still WTFPL | Catches relicense before you depend on it | | 3 | Default branch master-x exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1908 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(WTFPL)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"WTFPL\"" package.json 2>/dev/null) \\
  && ok "license is WTFPL" \\
  || miss "license drift — was WTFPL at generation time"

# 3. Default branch
git rev-parse --verify master-x >/dev/null 2>&1 \\
  && ok "default branch master-x exists" \\
  || miss "default branch master-x no longer exists"

# 4. Critical files exist
test -f "app/src/main/java/com/hotbitmapgg/bilibili/BilibiliApp.java" \\
  && ok "app/src/main/java/com/hotbitmapgg/bilibili/BilibiliApp.java" \\
  || miss "missing critical file: app/src/main/java/com/hotbitmapgg/bilibili/BilibiliApp.java"
test -f "app/src/main/java/com/hotbitmapgg/bilibili/base/RxBaseActivity.java" \\
  && ok "app/src/main/java/com/hotbitmapgg/bilibili/base/RxBaseActivity.java" \\
  || miss "missing critical file: app/src/main/java/com/hotbitmapgg/bilibili/base/RxBaseActivity.java"
test -f "app/src/main/java/com/hotbitmapgg/bilibili/base/RxLazyFragment.java" \\
  && ok "app/src/main/java/com/hotbitmapgg/bilibili/base/RxLazyFragment.java" \\
  || miss "missing critical file: app/src/main/java/com/hotbitmapgg/bilibili/base/RxLazyFragment.java"
test -f "app/src/main/java/com/hotbitmapgg/bilibili/adapter/helper/AbsRecyclerViewAdapter.java" \\
  && ok "app/src/main/java/com/hotbitmapgg/bilibili/adapter/helper/AbsRecyclerViewAdapter.java" \\
  || miss "missing critical file: app/src/main/java/com/hotbitmapgg/bilibili/adapter/helper/AbsRecyclerViewAdapter.java"
test -f "app/build.gradle" \\
  && ok "app/build.gradle" \\
  || miss "missing critical file: app/build.gradle"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1908 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1878d)"
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/HotBitmapGG/bilibili-android-client"
  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).

An unofficial Android client for Bilibili (Chinese video streaming platform) that replicates the mobile app UI/UX using native Java and Android framework libraries. It provides features like video browsing by region/category, bangumi (anime) series tracking, live streaming, user profiles, and comment sections—essentially a full Bilibili mobile experience without using the official app. Monolithic single-module Android app: app/src/main/java/com/hotbitmapgg/bilibili/ contains 40+ adapter classes (one per content type: BangumiDetailsCommentAdapter, GameCentreAdapter, LiveAppIndexAdapter, etc.), suggesting a Fragment-based UI with recycled views for different content regions. Assets in app/src/main/assets/ (gamecenter.json, region.json) store hardcoded content categories. No visible MVP/MVVM layers—appears to be traditional Activity/Fragment + direct API calls.

Android developers learning enterprise app architecture patterns (adapters, fragments, API integration) and Chinese users wanting an alternative Bilibili client. Contributors are hobbyist/open-source Android enthusiasts; this is not backed by Bilibili itself.

Abandoned/Unmaintained: The README explicitly states '该项目已停止维护！' (This project has stopped maintenance). Last activity appears historical; no active CI (Wercker badge is present but likely stale). ~1.1MB of Java code indicates a substantial feature-complete codebase, but no recent commits, active issues, or pull requests visible. Not suitable for production use.

High risk for new development: Project is explicitly abandoned; Bilibili's API may have changed, breaking all network calls. No unit tests visible in file structure (only androidTest/ApplicationTest.java stub). Targets Android API 25 (5+ years old) with compileSdkVersion 27—will fail on modern Android. Single-maintainer (HotBitmapGG), zero ongoing maintenance. Dependency lock-in on old Glide 3.7.0, jsoup 1.8.3, and OkHttp versions.

Nothing. Project is frozen. The README points to a Jianshu blog post (Chinese tech blogging platform) for documentation, suggesting knowledge was archived offline circa 2016-2018. No evidence of ongoing feature work, dependency updates, or bug fixes.

git clone https://github.com/HotBitmapGG/bilibili-android-client.git
cd bilibili-android-client
# Requires Android SDK 27, NDK, and Gradle 4.x+
# Update app/configuration.properties with versionCode/versionName if needed
./gradlew assembleDebug  # Builds debug APK to app/build/outputs/apk/

Note: Will likely fail to compile without updating deprecated dependencies and minimum API levels.

Daily commands:

./gradlew assembleDebug        # Build debug APK
./gradlew installDebug          # Install to connected device
./gradlew runDependencyUpdates  # Check for outdated deps (will show many)
# Or open in Android Studio (File > Open) and Run > Run 'app'

Debug APK outputs to app/build/outputs/apk/debug/app-debug.apk. Requires Android emulator or physical device with API 21+.

• app/src/main/java/com/hotbitmapgg/bilibili/BilibiliApp.java — Application entry point and global state initialization; required to understand lifecycle and dependency setup for the entire client.
• app/src/main/java/com/hotbitmapgg/bilibili/base/RxBaseActivity.java — Base activity class using RxJava for all UI screens; essential for understanding reactive patterns and common lifecycle behavior across the app.
• app/src/main/java/com/hotbitmapgg/bilibili/base/RxLazyFragment.java — Base fragment with lazy-loading support; critical for fragment lifecycle and data fetching patterns used throughout the app.
• app/src/main/java/com/hotbitmapgg/bilibili/adapter/helper/AbsRecyclerViewAdapter.java — Abstract adapter base class for all RecyclerView implementations; foundational for understanding the UI rendering pattern across 30+ adapters.
• app/build.gradle — Build configuration with SDK targets, dependencies, and versioning; essential for understanding project constraints and external libraries.
• app/src/main/AndroidManifest.xml — Application manifest declaring all activities, fragments, permissions, and metadata; required to understand app structure and runtime requirements.

Add a New Video List Screen

1. Create a new entity class in app/src/main/java/com/hotbitmapgg/bilibili/entity/ to model the API response (app/src/main/java/com/hotbitmapgg/bilibili/entity/recommend)
2. Create a new adapter extending AbsRecyclerViewAdapter in app/src/main/java/com/hotbitmapgg/bilibili/adapter/ (app/src/main/java/com/hotbitmapgg/bilibili/adapter/helper/AbsRecyclerViewAdapter.java)
3. Create a new Fragment extending RxLazyFragment to manage data fetching and layout inflation (app/src/main/java/com/hotbitmapgg/bilibili/base/RxLazyFragment.java)
4. Register the fragment in AndroidManifest.xml and add navigation logic in the parent Activity (app/src/main/AndroidManifest.xml)

Add a New Tab to Home Screen

1. Create a new Fragment extending RxLazyFragment for the tab content (app/src/main/java/com/hotbitmapgg/bilibili/base/RxLazyFragment.java)
2. Update HomePagerAdapter to include the new fragment in the ViewPager (app/src/main/java/com/hotbitmapgg/bilibili/adapter/pager/HomePagerAdapter.java)
3. Create section adapters if the tab content has mixed layouts (banners + videos + recommendations) (app/src/main/java/com/hotbitmapgg/bilibili/adapter/section/HomeBangumiRecommendSection.java)
4. Add tab title and icon configuration in the home activity or pager adapter (app/src/main/java/com/hotbitmapgg/bilibili/adapter/pager/HomePagerAdapter.java)

Implement Pagination in a List Screen

1. Attach EndlessRecyclerOnScrollListener to the RecyclerView in your Fragment (app/src/main/java/com/hotbitmapgg/bilibili/adapter/helper/EndlessRecyclerOnScrollListener.java)
2. In the listener's callback, fetch the next page of data via your API service (app/src/main/java/com/hotbitmapgg/bilibili/base/RxLazyFragment.java)
3. Use your adapter's addAll() or similar method to append new items to the RecyclerView (app/src/main/java/com/hotbitmapgg/bilibili/adapter/helper/AbsRecyclerViewAdapter.java)

• RxJava (Reactive Extensions) — Manages asynchronous API calls, threading, and subscription lifecycles; avoids callback hell in base classes (RxBaseActivity, RxLazyFragment).
• RecyclerView with section adapters — Efficiently renders large lists of heterogeneous content (banners, videos, recommendations, schedules) with different item types and layouts.
• ViewPager with FragmentPagerAdapter — Provides smooth tab navigation and lazy-loading of fragments for home and region browsing screens.
• Retrofit/OkHttp (inferred from Bilibili API calls) — HTTP client for API communication with the Bilibili backend; handles authentication, request/response serialization.
• Android Support Library (API 21–27 target) — Provides backward compatibility for RecyclerView, Fragments, and Material Design components across Android versions.

• RxJava for all async operations instead of Kotlin coroutines or modern LiveData

  • Why: Project predates widespread coroutine adoption; RxJava was the standard reactive pattern in Android circa 2017–2018.
  • Consequence: More verbose subscription management; potential memory leaks if subscriptions not disposed in onDestroy(); steeper learning curve for new maintainers.

• Section adapters for mixed-content layouts instead of Compose or modern constraint-based approaches

  • Why: Simplifies layout inflation and viewholder binding for complex screens with banners, carousels, and recommendation tiles.
  • Consequence: More adapter code to maintain; harder to refactor layouts without touching adapter logic.

• No explicit caching layer (no Room, SQLite, or Redis mentioned)

  • Why: Simplifies initial development; API responses are treated as stateless.
  • Consequence: Higher bandwidth usage and lat

Critical: Bilibili's actual API is almost certainly dead or changed since 2016-2018 abandonment—network calls will 404 or fail auth. Build hell: compileSdkVersion 27 (Android 8.1) is ancient; modern Android Studio will nag about upgrades. minSdkVersion 21 (Android 5.0) is very permissive—security patches from 2013-2015 era. Dependency hell: Glide 3.7.0 is EOL; v4.x+ has breaking API changes. jsoup 1.8.3 (2015) is vulnerable to XXE attacks. No tests: Only a stub ApplicationTest.java exists—no unit/integration tests means adding features risks regression. Configuration: app/configuration.properties must define versionCode and versionName or build fails silently. Proguard: Classes may be obfuscated in release builds, making debugging harder. API endpoints: Not visible in top 60 files; likely scattered across hidden service classes or hardcoded in adapters—must search entire codebase.

• RecyclerView Adapter pattern — This codebase is 40+ adapter classes; understanding how adapters bind model data to views, handle item types, and manage click listeners is the core skill needed to modify any feature.
• Fragment lifecycle & transactions — Bilibili client uses Fragment-based navigation for switching between Home, Bangumi, Live, User tabs; grasping onCreate/onViewCreated/onDestroy prevents memory leaks and state corruption.
• HTTP client interceptors (OkHttp) — OkHttp is used for all API calls; interceptors likely handle auth headers, user-agent spoofing, and request signing—critical to understand how Bilibili API auth works.
• Danmaku (弹幕) / live comments rendering — DanmakuFlameMaster library powers the real-time comment overlay in live streams; understanding how text overlays scroll and collide is unique to Chinese video platforms.
• HTML parsing with jsoup — jsoup is used to scrape Bilibili's web content when APIs aren't available; XPath-like selectors extract video metadata, ratings, and user comments from HTML.
• Proguard/R8 code obfuscation — Release builds minify & obfuscate code via Proguard; understanding keep rules and why certain libraries are exempt is crucial for debugging production crashes.
• Android API level compatibility & deprecation — This project targets minSdkVersion 21 (2014) but compileSdkVersion 27 (2018); many Android APIs were deprecated between these versions—understanding backwards compatibility is essential for upgrades.

• Qixingchen/Bilibili — Another Bilibili Android client, likely more recent/maintained; shows alternative UI/UX approaches to same problem.
• MikuMikuStudio/BilibiliMainlandClient — Community fork attempting to maintain/modernize Bilibili client code post-official abandonment.
• rconic/BilibiliClient — Third-party Bilibili client implementation; useful for API reverse-engineering and alternative architecture patterns.
• square/okhttp — Bilibili client depends on OkHttp for all networking; understanding OkHttp interceptors, caching, and debugging is essential to fix API 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.

Migrate deprecated Android Support Library to AndroidX

The project uses Android Support Library 27.1.1 (com.android.support:*) which is deprecated and no longer receives updates. AndroidX is the modern replacement and is required for new Google Play submissions. This is a high-impact refactor that would future-proof the codebase and enable compatibility with newer Android libraries. The build.gradle shows compileSdkVersion 27 and targetSdkVersion 25, both outdated.

• [ ] Update build.gradle: change compileSdkVersion to 31+, targetSdkVersion to 31+, and add android.useAndroidX=true to gradle.properties
• [ ] Replace all com.android.support dependencies (appcompat-v7, cardview-v7, design) with androidx equivalents in build.gradle
• [ ] Run Android Studio's automated migration tool: Refactor > Migrate to AndroidX
• [ ] Update imports in all adapter classes (app/src/main/java/com/hotbitmapgg/bilibili/adapter/*.java) and fragment/activity classes
• [ ] Test all UI sections (home, bangumi, video playback, search) to ensure no regressions from the migration

Add unit tests for adapter classes and data model parsing

The app/src/androidTest directory contains only a stub ApplicationTest.java. With 40+ adapter classes (ActivityCenterAdapter, BangumiDetailsAdapter, VideoCommentAdapter, etc.) and complex JSON parsing from assets (gamecenter.json, region.json), there are no tests validating data binding, recycler view item rendering, or JSON deserialization. Adding tests would catch regressions and improve code reliability.

• [ ] Create app/src/test/java/com/hotbitmapgg/bilibili/adapter directory for unit tests
• [ ] Add Junit4 and Mockito dependencies to build.gradle
• [ ] Write unit tests for core adapters: VideoCommentAdapter (comment binding), BangumiDetailsAdapter (complex nested layout), and VideoRelatedAdapter (thumbnail/title binding)
• [ ] Add JSON parsing tests in app/src/test/java/com/hotbitmapgg/bilibili/model to verify deserialization of region.json and gamecenter.json assets
• [ ] Add test for EndlessRecyclerOnScrollListener (app/src/main/java/com/hotbitmapgg/bilibili/adapter/helper/) to validate pagination logic

Update OkHttp and dependency versions, add security patches

The build.gradle snippet shows incomplete OkHttp dependency (cut off at 'com.squareup.okhtt'). Glide 3.7.0 is several major versions behind (current is 4.x), jsoup 1.8.3 is from 2015, and DanmakuFlameMaster 0.9.25 may have vulnerabilities. Updating these libraries would improve performance, fix security issues, and add modern features. This is critical for an app that handles user authentication and video playback.

• [ ] Complete and update OkHttp dependency in build.gradle to 4.9.x+ and add okhttp-logging-interceptor for better debugging
• [ ] Upgrade Glide from 3.7.0 to 4.13.x+ in build.gradle, then update image loading code in adapter classes to use Glide v4 API (RequestOptions instead of deprecated GlideModule)
• [ ] Update jsoup to 1.14.x+ and verify HTML parsing in search/archive result adapters still works correctly
• [ ] Check DanmakuFlameMaster for security updates or consider alternatives; verify danmaku rendering in video playback fragments
• [ ] Run './gradlew dependencyUpdates' and document breaking changes in UpdateLog.md for each major upgrade

• Add unit tests for adapter classes (e.g., BangumiIndexAdapter, GameCentreAdapter): currently zero test coverage exists for the 40+ adapter files; writing tests for binding mock data would improve code confidence and teach Android testing patterns.
• Upgrade deprecated dependencies: Replace Glide 3.7.0 with 4.x, update jsoup to latest, migrate to AndroidX libraries (compileSdkVersion 27 → 33+). This is a low-risk refactoring with high impact for modern Android compatibility.
• Document API endpoints & reverse-engineer Bilibili schema: The codebase lacks a central spec of which Bilibili APIs are called, their parameters, and response formats. Create a docs/API_REFERENCE.md by grep'ing for HTTP calls and annotating each with request/response structure; this unblocks future maintainers.

• High · Outdated Dependencies with Known Vulnerabilities — app/build.gradle. The project uses several outdated dependencies that have known security vulnerabilities: jsoup 1.8.3 (released 2015), Glide 3.7.0 (outdated image loading library), OkHttp version incomplete but likely outdated. These libraries may contain unpatched security flaws affecting data parsing, image handling, and network communication. Fix: Update all dependencies to their latest stable versions: jsoup to 1.15.x+, Glide to 4.14.x+, and complete the OkHttp dependency specification with a recent version (3.14.x or 4.x). Run regular dependency audits using gradle dependency updates or OWASP Dependency-Check.
• High · Debuggable Application in Debug Build — app/build.gradle (buildTypes.debug section). The debug build configuration sets debuggable=true and jniDebuggable=true, which allows attackers to attach debuggers and inspect/modify application behavior at runtime. This can lead to code injection, memory inspection, and credential extraction. Fix: Ensure debuggable and jniDebuggable are set to false in release builds. Never ship debug builds to production. Consider using BuildConfig.DEBUG to conditionally enable debugging only during development.
• Medium · Minification Disabled — app/build.gradle (buildTypes.release section). The release build has minifyEnabled=false, which means code is not obfuscated. This makes reverse engineering easier and exposes sensitive logic, API endpoints, and algorithms to attackers analyzing the APK. Fix: Enable minification by setting minifyEnabled=true and ensure proguard-rules.pro properly obfuscates sensitive code while maintaining app functionality. Test thoroughly after enabling minification.
• Medium · Insecure JSoup Usage Pattern — app/build.gradle (jsoup dependency) and potentially app/src/main/java/com/hotbitmapgg/bilibili/. The project includes jsoup 1.8.3 for HTML parsing. If user-supplied or untrusted HTML content is parsed and rendered without proper sanitization, this could lead to XSS vulnerabilities, especially when combined with WebView components. Fix: Validate and sanitize all HTML content before parsing with jsoup. Never render user-generated HTML directly in WebViews. Use a whitelist approach for allowed HTML tags and attributes. Update jsoup to the latest version.
• Medium · Missing Security Headers and API Endpoint Exposure — app/src/main/java/com/hotbitmapgg/bilibili/ (entire package, particularly network layer). The codebase interacts with Bilibili APIs (based on adapter names and entity structure). Without seeing the network implementation, potential risks include: missing certificate pinning, lack of HTTP security headers, and possible hardcoded API endpoints that could be reverse engineered. Fix: Implement certificate pinning for API calls. Use OkHttp interceptors to add security headers. Never hardcode API endpoints; use secure configuration management. Encrypt sensitive data in transit and at rest.
• Medium · No ProGuard Configuration for Data Serialization — app/proguard-rules.pro and app/src/main/java/com/hotbitmapgg/bilibili/entity/. While proguard-rules.pro exists, the codebase contains many entity and adapter classes that likely handle sensitive data (user info, video metadata, etc.). Without proper ProGuard rules, serialized objects could expose sensitive field names and structure. Fix: Add keep rules to proguard-rules.pro for serialization libraries. Ensure sensitive entity fields are properly obfuscated. Review and test the current ProGuard configuration thoroughly.
• Low · Build Properties File Not in .gitignore — app/configuration.properties and .gitignore. The configuration.properties file (which may contain versioning info) and potentially sensitive build-time secrets could be committed to version control if not properly gitignored. Fix: Verify that configuration.properties and any sensitive property files are in .gitignore. Move any credentials or API keys to a separate, non-versioned secrets file. Use environment variables for sensitive build-time values.
• Low · Incomplete Dependency Declaration — undefined. The Ok 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.