A polished, personal-use, serverless Android game library. Add a repository URL (PlayZip, AnkerGames, SteamRip, or any file listing) and GameVault indexes that one site into a fast, searchable, offline catalog of downloadable games.
The website acts as the invisible backend; your app is the frontend. You never feel like you're browsing the site — you're browsing a native game library that is backed by it.
Website URL
│
▼
Indexer (in-process crawler)
│
▼
Local SQLite database (metadata only)
│
▼
Library UI (browse / search / filter / sort — offline)
│
▼
Tap Download → resolve flow → built-in download manager
There is no server: no Flask, no localhost HTTP server, no QR connection, no LAN discovery, no backend API. Everything runs inside the app process (Chaquopy), and the UI is static files loaded straight from the APK's assets.
Open app → Repositories → Open a repository → Game Library → Download
- Repositories — home screen lists your mounted sites as library cards (game count, last update). The official repositories (PlayZip, AnkerGames, SteamRip) are one tap away, plus a Custom URL option.
- Games / Downloads / Favorites / Settings — bottom navigation. The Favorites tab collects starred games across all repositories.
- No dialogs on startup — the app opens straight into the repository list with an elegant empty state when you haven't added anything yet.
- One modal at a time — every dialog (Add Repository, Edit Repository, Collections, confirmations) shares a single modal layer with a proper backdrop, so dialogs never stack.
- Advanced is tucked away — cookies, headers, and scan depth live under "Advanced Settings" inside Edit Repository, not in the main flow.
Every website you mount becomes its own library card:
🧠 HuggingFace Models 🎮 ROM Collection 📦 APK Repository
https://huggingface.co/.. https://…/roms https://…/apks
2,431 assets 845 assets 412 assets
Updated 5 min ago Updated Yesterday Updated Today
Each library remembers its original URL, last scan, asset count, update stats (new/updated/removed), crawl depth, and error state.
Refreshing a library never rescans from zero:
Checking for updates…
+12 new assets · 3 updated · 1 removed
Assets are diffed by URL + content signature (filename, size, version, type, thumbnail, MIME). Only changes touch the database.
Once indexed, everything is cached in SQLite:
- Browse libraries and their catalogs with no network
- Instant search, type filter (
.zip,.7z,.apk,.gguf, …) and sorting - Only downloading or refreshing needs network
Many sites hide downloads behind buttons, interstitial pages, forms, or
JavaScript instead of exposing a direct .zip link. The indexer discovers
these download flows:
- Buttons & links — anchors,
<form action>(GET/POST with fields),onclick/onmousedownURLs,data-href/data-downloadattributes,fetch()/XHR calls, embedded JSON and JS variables, and/download/...or/api/download/...routes are all resolution candidates. - Execute the flow — candidates are requested the way the page would trigger them (GET with a ranged probe, or POST with form data), with a desktop User-Agent and the page URL as Referer.
- Follow redirects — HTTP 301/302/307/308 chains are followed to the final host (typically a CDN).
- Record, never download — the final CDN URL, filename (from
Content-Dispositionwhen present), filesize, and MIME type are stored; file bodies are never saved during indexing. - Magic-byte sniffing — unknown
application/octet-streamresponses are identified from their first bytes (PKzip,7z,Rar!, gzip, xz, PDF, GGUF). - JSON APIs — JSON/text responses (including mislabeled ones) are read in full (small only) and any URLs inside are resolved recursively.
- Interstitial pages — an HTML landing page (e.g.
/download/123) is enqueued as a crawl page and processed for further assets. - Re-resolution on demand — when you tap Download, the app re-executes the stored download flow if the cached URL is stale, then queues the file.
- The CDN is never crawled — the original website is the only crawl domain; external hosts only ever appear as final file URLs.
Some repositories (Cloudflare-protected, JS-rendered, or login-walled) can't be indexed by a plain HTTP fetcher. AssetVault's built-in browser covers those:
- Browse site — opens the library URL inside the app's WebView in PC mode with native ad-blocking, so you can log in, pass a captcha, or let the site's JavaScript render the real catalog.
- Session (
🍪) — copies the WebView's cookies for the current page and library domain onto the library. Every later index/download runs with that logged-in session. - Capture page (
📷) — grabs the fully-rendered DOM of the current page and indexes it into the open library (listing pages become game/asset cards; single game pages become metadata entries). Use it page-by-page when the site blocks recursive crawling. - Import from browser session — inside Library Settings, one tap fills the Cookies (JSON) field from the WebView's session.
The floating overlay on every browsed site (left, Capture, Session) brings these actions back with one tap, and PC mode stays active the whole time.
- Same domain only — the crawler never leaves the site; links to facebook/google/youtube/CDNs are ignored (unless they are the actual file host for an asset link).
- Recursive — internal links are normalized, deduplicated, and queued (BFS) until the queue is empty.
- Pagination —
next/older/load morelinks and?page=/page/Noffset=cursor=patterns are followed automatically. - Depth — configurable per library: 1 / 3 / 5 / 8 / unlimited (default 8). A safety cap of 2000 pages prevents runaway crawls; you can Stop at any time.
- Deduplication — by normalized URL, plus filename+size when known.
Only archive/package files are collected. Images, audio, video, CSS/JS, fonts, analytics, ads and other resources are ignored:
.zip .7z .rar .tar .tar.gz .gz .xz .apk .apks .xapk .obb .iso .img .bin .gguf .safetensors .ckpt .pt .onnx .pdf
While indexing, the UI shows:
Pages scanned: 241 Assets found: 983 Queue remaining: 37
Current page: /downloads/models/page/11
- Queue with concurrent workers, progress / speed / ETA
- Mirror fallback, HTTP Range resume, parallel chunked downloads
- SHA-256 verification (when a checksum is provided)
- Speed limiter, filename cleanup, cancel, retry, clear-finished
- Polite delay between downloads
- Not a web mirror — pages are inspected, never saved.
- Not a media library — only whitelisted archives/packages are listed.
- Not a server — everything runs on-device.
- Android WebView (UI) + WebViewAssetLoader (static files from APK assets)
- Chaquopy — Python 3.12 embedded in the APK; crawler + SQLite run in-process
- httpx + BeautifulSoup — page fetching and parsing
- SQLite — libraries, assets, and download history (all local)
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
python cli.py crawl https://example.com/downloads --depth 8
python cli.py download https://example.com/files/game.zip --title "My Game"
python cli.py library add https://example.com/models --depth 5
python cli.py library list
python cli.py library scan 1
python cli.py library assets 1 --query llama
python cli.py library resolve 1 3 --downloadcd android
export ANDROID_HOME=/opt/android-sdk # or wherever your SDK lives
./gradlew assembleDebugAPK: android/app/build/outputs/apk/debug/app-debug.apk. Building needs an
Android SDK, NDK, and Python 3.12 (Chaquopy compiles the Python code and pip
packages into the APK; the first build needs network). The Python package
(gamevault/) and web UI (static/) are synced into the Android source tree
before each build.
The SQLite database lives at data/gamevault.db on PC (libraries, assets,
download history); downloaded files land in data/downloads by default. On
Android everything lives in the app's internal storage.