Tamper-Proof Content Blocker & Device Protection App System-Level Mobile Threat Protection & Loca...Tamper-Proof Content Blocker & Device Protection App System-Level Mobile Threat Protection & Loca...
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Tamper-Proof Content Blocker & Device Protection App
System-Level Mobile Threat Protection & Local Network Filtering
The Challenge
Standard Android content filters are easy for users to bypass, disable, or uninstall, while third-party remote VPNs introduce severe latency and data privacy risks.
The Solution & Impact
Built a Kotlin-native Android application that enforces device-level content filtering and anti-tampering protection locally without sending user traffic to external servers.
Local VPN & DNS Filtering: Intercepts system-wide DNS packets via a local VpnService TUN interface to block prohibited domains locally with zero latency.
System-Level Security Hooks: Utilized Android Accessibility Services and Device Admin APIs to prevent unauthorized uninstallation, force-stopping, or setting bypasses.
Tamper-Proof Lock: Enforced settings locking via an encrypted, randomized password generator to ensure non-bypassable enforcement.
Tech Stack: Kotlin | Android SDK | VpnService | Accessibility APIs | DeviceAdminReceiver | Jetpack Compose
Post image
Post image
Post image
Saad's avatar
Doing the DNS filtering locally through VpnService instead of routing traffic out is the right call. Curious how the Accessibility Services and Device Admin combo went with Play review, that pairing usually draws a lot of policy questions on anti-uninstall apps.
Muneeb's avatar
Hey Saad, good catch! 😄 Yeah, going with the local VpnService was pretty much a no-brainer—less traffic taking a scenic route through some external server, better performance, and fewer hops for the packets to complain about.
And yep, Play Store is basically the security guard...
Saad's avatar
Disclosure screen before requesting Accessibility is exactly what reviewers look for now. Did you run into the Restricted Settings flow on Android 13+, where sideloaded APKs block Accessibility grants outright, or is this shipping through Play only?
Muneeb's avatar
Yep, I came across that as well. Android 13+ is a bit strict with sideloaded APKs, so it blocks Accessibility and shows the “Restricted setting” warning.
For testing, I’m keeping it simple users just need to go to App >Allow restricted settings, and then Accessibility can be...
Saad's avatar
That tracks, Play's package verifier marks the install as coming from a trusted source so Android skips the extra restriction. Worth keeping the Allow restricted settings steps documented anyway, reviewers and testers often sideload the APK directly before it ever hits Play.
Saad's avatar
Keeping Device Admin scope minimal is the right call, Google's been rejecting anti-uninstall apps that request broad policies. Curious if you're watching the slow deprecation path there, since newer restriction APIs don't have a clean replacement yet for this exact use case.
Back to feed
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started