Android's 24-Hour Sideload Hold: What the New Process Reveals About Platform Control

Android has long carried its openness as a badge. Unlike iOS, you could grab an APK from a developer’s website, a third-party store, or your own build server, enable installs from that source, and install the thing. No notarization, no waiting, no gatekeeper beyond Play Protect’s scan-and-warn flow. That model is changing. Google has now detailed a formal 24-hour review period for apps sideloaded outside the Play Store, and the technical and regulatory context around it is worth unpacking carefully.

How Android’s Sideload Pipeline Works Today

Before examining what changes, it helps to understand what’s already in place. Since Android 8.0, the old system-wide “Unknown Sources” toggle was replaced with a per-app REQUEST_INSTALL_PACKAGES permission. Each installer, whether a browser, a file manager, or a third-party app store, must declare this permission and the user must explicitly grant it to that specific app through Settings. Installation itself goes through PackageInstaller.Session: the installer streams APK bytes, calls commitSession(), and PackageManagerService handles signature verification, manifest parsing, SDK compatibility checks, and storage allocation.

Play Protect intercepts this flow. When a user attempts to sideload an APK, Play Protect submits the file’s hash to Google’s servers. If the hash is unknown, Play Protect may upload portions of the APK itself for cloud-side static and dynamic analysis. Since 2023, Google added on-device ML-based scanning for novel malware that doesn’t match known signatures. The user sees a “Scanning app” dialog. Depending on what Play Protect finds, the install proceeds, the user gets a warning they can override, or the install is blocked outright for severe threats.

This system already represents meaningful friction. But it resolves in seconds or minutes, not hours. The new policy changes that.

What the 24-Hour Process Actually Does

The formalized review period means an APK from an unverified source enters a queue rather than completing immediately. Google’s infrastructure receives the app, subjects it to a more thorough review pass than the real-time scan allows, and the installation either completes or is flagged within that window.

A 24-hour hold opens analysis options that real-time scanning cannot. Dynamic analysis, running the app in a sandboxed environment and observing its behavior, is computationally expensive and time-consuming. Signature-based scanning catches known malware; behavioral analysis in a controlled environment is better positioned to catch obfuscated or novel threats that check for sandbox conditions. Google’s cloud infrastructure can also cross-reference metadata, certificate chains, and developer history in ways that a millisecond hash lookup cannot.

The practical comparison here is Apple’s notarization process for iOS, which Apple introduced in the EU under Digital Markets Act requirements with iOS 17.4. Apple’s notarization is automated and targets same-day turnaround, but it performs automated security checks, API usage validation, and malware scanning before issuing a cryptographic ticket that iOS verifies at install time. The difference is that Apple frames notarization as a technical prerequisite for distribution; Google is framing the 24-hour hold as a review step the user waits through. Both achieve the same outcome: the platform retains a gate over what installs, even outside the first-party store.

The DMA Thread Running Through This

The EU’s Digital Markets Act designated Google as a gatekeeper in September 2023, with a compliance deadline of March 7, 2024. Article 6(4) of the DMA requires gatekeepers to allow third-party app installation and alternative app stores without technical restrictions that disadvantage them relative to the first-party store. The European Commission opened formal non-compliance investigations into Google’s app distribution practices shortly after the compliance deadline, partly on the grounds that Play Protect warnings and extra confirmation dialogs constituted illegal obstruction.

This creates a narrow path for Google. The DMA prohibits Google from making sideloading technically harder than Play Store installs without justification. But “security” is a recognized justification under the DMA, provided the measures are proportionate and documented. A formalized review process, with a published rationale tied to malware analysis, is structurally easier to defend before the EC than informal friction like interstitial warnings that can be dismissed. Google is essentially converting what was opaque friction into a documented process, which is better for regulatory compliance even if it extends the wait for users.

Apple faced the same calculation. Its notarization process drew criticism from the EC over the Core Technology Fee and the authorization requirements for marketplace operators, but the notarization check itself has not been the primary target of non-compliance findings. A technically grounded, automated review process is defensible in ways that “we show scary warnings” is not.

The Honest Question About What 24 Hours Buys

The security case for a 24-hour hold is real but bounded. Dynamic analysis helps. Cross-referencing developer history and certificate chains helps. Catching malware that specifically evades real-time scanning helps. But the threat model for sideloaded apps is not primarily “unknowing users downloading mainstream apps that turn out to be malware from a trusted source.” It is users deliberately going outside the Play Store to install something Google would not allow, whether that is an app with functionality Google prohibits, a modified version of a Play Store app, an app from a developer who cannot or will not go through the Play Store, or, yes, sometimes actual malware.

The 24-hour hold addresses the last category reasonably well. It does comparatively little for the others, and it imposes cost on all of them equally. A developer distributing a legitimate app outside the Play Store, perhaps because they object to Google’s 15-30% commission, now has users waiting a day to install their product. An enterprise deploying an internal application through MDM or a manual install process hits the same queue. The signal that 24 hours of review provides against sophisticated, targeted threats is also limited: a sufficiently patient attacker can verify their payload passes review before distributing it.

This is not an argument against the policy. The realistic target is the large volume of low-sophistication malware, scam apps, and fraudulent packages that circulate through informal channels. Against that threat, a more thorough automated review has genuine value. Play Protect’s real-time scanning expansion in 2023-2024 already demonstrated that cloud-backed analysis catches things that on-device hashing misses. More time is more analysis.

What This Means for Android’s Openness Model

Android’s historically permissive sideloading model was always something of a marketing narrative layered over real friction. The per-app install permission, Play Protect warnings, the ability for carriers and OEMs to disable sideloading entirely on their devices: these have always created meaningful gaps between “Android allows sideloading” and the user experience of actually doing it.

The 24-hour review period is a continuation of that trajectory, not a departure. What changes is that the friction is now temporal rather than interstitial. You can no longer install in the moment; you submit and wait. For most users this distinction is academic because most users are not sideloading anything. For developers distributing outside the Play Store, for power users managing their own devices, and for the third-party app store ecosystem that the DMA was partly designed to enable, a one-day queue is a real friction point that will suppress some portion of installs.

The comparison that matters is not Android versus iOS, but Android today versus Android two years ago. Google has progressively reduced the practical openness of sideloading while maintaining it as a technical capability. The per-app permission model added friction in 2018. Enhanced real-time scanning added friction in 2023. The fraud-prevention blocks on apps requesting Accessibility or Notification Listener permissions outside the Play Store added friction in 2024 in several markets. The 24-hour hold is the next step in the same direction.

None of these steps individually converts Android into a walled garden. Cumulatively, they shift the cost-benefit calculation for anyone who builds outside the Play Store. That is worth watching closely, particularly as the EC continues its non-compliance review and determines whether Google’s documented, security-framed processes satisfy DMA requirements or represent a more sophisticated version of the obstruction the regulation was meant to address.