Stable · v1.0.0> android / mobile network diagnostics
Diagnose mobile network accessibility and observable signs of whitelist-mode restrictions.
WhiteListChecker runs checks through an explicitly acquired cellular Network, even when Wi-Fi remains the phone's default connection. It combines HTTPS reachability with DNS diagnostics, stores results locally and monitors changes over time.
$ context
WhiteListChecker does not have access to an operator's internal filtering rules. It reports observable network behavior and deliberately avoids presenting the result as proof of a specific operator-side mechanism.
The cause can be routing, DNS, TLS, temporary connectivity loss, a VPN or tunnel, device configuration, or network-side filtering. A single “works / does not work” check is not enough for a useful diagnosis.
The app acquires a separate cellular Network, runs network-bound HTTPS and DNS checks, keeps DNS as secondary diagnostics, then stores the resulting state locally for history, statistics and monitoring.
> capabilities
The stable release focuses on direct cellular diagnostics without requiring a project-owned backend or account.
Uses ConnectivityManager.requestNetwork(...) to obtain TRANSPORT_CELLULAR without process-wide bindProcessToNetwork.
Checks editable LOCAL and FOREIGN target groups through the acquired cellular Network with normal TLS certificate and hostname verification.
Supports editable resolvers, UDP/53, TCP/53 fallback and cellular hostname resolution. DNS remains a supporting signal rather than the sole classifier.
Room stores check history, per-target results, statistics and whitelist timeline. Data can be exported to CSV, JSON or TXT.
Scheduled checks use WorkManager, while explicitly started continuous monitoring uses a foreground service.
Supports local Android notifications and an optional personal Telegram flow through a user-owned Cloudflare Worker and Telegram bot.
Checks official GitHub Releases asynchronously, filters stable/prerelease versions and lets the user open the official release page.
Bug report and feature request actions open GitHub Issue Forms without embedding a GitHub PAT or OAuth write credential in the APK.
User-facing dialogs, notifications, accessibility descriptions and errors are localized through Android resources.
$ signal_pipeline
Site reachability is the primary classification signal. DNS availability is secondary, so one unavailable public resolver does not automatically become a mobile DNS failure.
> interface
These are current screenshots from the project's own repository.
$ architecture
The app uses MVVM with domain use cases and a manual AppContainer composition root. Checker logic, persistence and classification stay outside Compose UI components.
Jetpack Compose + Material 3, MainViewModel and AppUpdateViewModel.
WhitelistCheckUseCase, CheckAndNotifyUseCase, CheckForAppUpdateUseCase and WhitelistStateClassifier.
CellularNetworkProvider, MobileSiteChecker, CellularDnsResolver and OkHttp with the cellular Network socket factory where required.
Room schema 8 for history/statistics/timeline and DataStore Preferences for application, checker, notification and monitoring settings.
WorkManager for periodic checks and ActiveMonitoringService for explicitly started foreground monitoring.
Public GitHub Releases API for update discovery and a user-owned Cloudflare Worker for personal Telegram integration.
$ engineering
These constraints are part of the product design, not missing features.
The checker obtains a dedicated cellular Network and creates DNS/HTTPS traffic through it. Process-wide bindProcessToNetwork is intentionally not used.
Site checks are the primary signal. DNS remains secondary so failures of public resolvers do not create misleading overall states.
A proxy or tunnel changes the path being measured. Supporting it as a checker transport would undermine the purpose of direct cellular diagnostics.
Room schema 8 removes the obsolete pending_public_reports table through migration 7 → 8 while preserving history, statistics, targets and settings.
WorkManager handles scheduled periodic work. Foreground Service is reserved for active monitoring explicitly started by the user.
The app checks public GitHub Releases, filters prereleases and opens the official release page. APK download and installation remain under user and Android control.
> technology
> privacy
LOCAL-FIRSTSince v1.0.0, the old project-owned central/public service has been removed. Checks, history and statistics stay on the device.
> security
SECURITY BOUNDARIESHTTPS target checks keep normal TLS certificate and hostname verification. The APK does not contain a GitHub PAT/OAuth write token or Telegram BOT_TOKEN.
> build target
$ stable_release
The first stable release was published on 25 August 2026. The official APK and checksum file are distributed through GitHub Releases.
53EE6B90AA3D2FB5A928519E3F6B411DD4572E1C2EE45519797449C4F3EB3ED3> project links
GitHub remains the source of truth for code, releases, issues and technical documentation.