--- title: "Blocking APK sideloading and unmonitored installs" description: "Sideloading an APK installs a fresh browser or app from outside the store, skipping every install lock. The managed-policy and account moves that close it." url: https://tkot.com/journal/block-apk-sideloading-and-unmonitored-installs/ canonical: https://tkot.com/journal/block-apk-sideloading-and-unmonitored-installs/ author: "Arya Stark" published: 2026-06-07 updated: 2026-06-07 category: "Loopholes" tags: ["sideloading", "apk", "android", "side doors", "block porn"] lang: en --- # Blocking APK sideloading and unmonitored installs > **TL;DR** On Android, sideloading installs an app from an APK file outside the official store, which routes around a store-level install lock and can drop in an unmonitored browser or VPN. Close it by disabling install-from-unknown-sources, ideally through a managed device policy a trusted account controls, and lean on below-the-app filtering (DNS and screen layer) so even a sideloaded app inherits the block. TKO'T filters beneath the app, so a sideloaded browser changes nothing. You can lock the official app store on Android and still leave a back entrance open: sideloading, installing an app directly from an APK file you downloaded, no store involved. It is the exact same threat as [downloading a fresh browser](/journal/stop-a-fresh-browser-from-reopening-everything/), just through a side door that a store-level install lock does not cover. Close it and you close the Android version of the new-app loophole. The fix is the familiar pattern: disable the install-from-unknown-sources permission with authority you do not hold, and filter beneath the app so even a sideloaded browser inherits the block, which is what [TKO'T](/#download) does, free. Defense-only, naming the route only to shut it. ## Why a store lock does not cover sideloading Blocking installs in the official store stops store downloads, but an APK is a file, and installing it uses a separate permission, install from unknown sources. If that permission is available, the store lock is only half the wall: a determined person downloads the APK and installs a clean, unmonitored browser or VPN that the store never saw. This is the same independence problem as a [new browser](/journal/stop-a-fresh-browser-from-reopening-everything/) or a [VM](/journal/close-virtual-machine-and-remote-desktop-bypass/), arriving through Android's direct-install path instead of the store. ## Disable unknown-source installs, with held authority The direct close is turning off the ability to install from unknown sources, and the durable version puts that setting beyond your own reach: **Managed policy is the strong version.** A device enrolled under a [managed policy](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies) whose controlling account a trusted person holds can disallow installing apps from unknown sources entirely, so the user cannot grant the permission back. This is the same enrollment that closes [safe mode](/journal/close-safe-mode-and-boot-level-bypass-routes/) and [developer options](/journal/lock-developer-options-and-usb-debugging/), one profile covering the whole family of Android bypasses. **Lock developer options too.** Sideloading often travels with developer options and USB installs, so disabling those by the same policy closes the cable-based version of the route alongside the on-device one. ## Filter beneath the app regardless The deeper insurance is that real enforcement should not depend on which apps exist. [Pinned DNS filtering](https://developers.cloudflare.com/1.1.1.1/setup/) answers lookups for every app including a sideloaded one, and an [on-device screen layer](https://datatracker.ietf.org/doc/html/rfc8484) judges what renders in any app regardless of how it was installed. So even if an APK gets onto the device, it opens onto the same filtered network and the same watching screen, the install lock is the wall and below-the-app filtering is the backstop, exactly as with the [app store](/journal/lock-app-store-and-account-switching-iphone/). Keep [tamper resistance](/journal/tamper-resistant-porn-blocker-that-survives-weak-moments/) underneath so the unknown-sources setting is not re-enabled in a weak moment. The honest ceiling is the Android-wide one: a determined owner with full control of an unmanaged device can grant permissions back, which is precisely why the managed-policy version, with the controlling account held by someone else, is the one that actually holds. For an adult locking their own phone or a parent locking a kid's, that held account is the difference between a setting and a wall. ## Frequently asked questions ### How do I block sideloading APKs so I don't install a fresh browser? Disable install-from-unknown-sources, and make it stick by enrolling the device under a managed policy whose controlling account a trusted person holds, so the permission cannot be granted back. Lock developer options and USB installs by the same policy to close the cable route. Then filter beneath the app with DNS and a screen layer like TKO'T, free, so even a sideloaded browser inherits the block. ### Why does locking the app store not stop sideloading? Because sideloading installs an app from an APK file using a separate permission, install from unknown sources, that the store lock does not touch. The store lock stops store downloads; the APK arrives through a different door. You have to disable the unknown-sources permission specifically, ideally through a managed policy, to close that second route. ### How do I permanently disable install from unknown sources on Android? The permanent version is a managed device policy: a controlling account held by someone you trust can disallow unknown-source installs so the device user cannot re-enable them. Toggling it off in settings alone is reversible by anyone with the device, which is why the held-account version is the one that actually holds against a weak moment. ### Will a sideloaded app still be blocked by my filter? If your filtering lives below the app layer, yes: pinned DNS answers lookups for every app including a sideloaded one, and an on-device screen layer judges what renders in any app regardless of how it was installed. That is why below-the-app filtering is essential, it means a sideloaded browser opens onto the same wall as every other app rather than a clean slate. ### Can a determined person still sideload anyway? On a fully unmanaged device they control, eventually yes, they can grant the permission back, which honest tools admit. The managed-policy version, with the controlling account held by someone else, removes that ability, and below-the-app filtering plus tamper resistance covers whatever does get installed. The goal is the usual one: make the bypass slow and credential-gated, not impossible. --- Source: https://tkot.com/journal/block-apk-sideloading-and-unmonitored-installs/ Author: Arya Stark