Google just made it significantly harder to install apps from outside the Play Store. Their new process requires a 24-hour waiting period for sideloaded apps that haven't been verified by Google Play Protect, during which the APK is uploaded to Google's servers for scanning. Install an app from a third-party source, and you wait a full day before you can use it. The security rationale is straightforward: malware-laden APKs are a real problem, especially in regions where sideloading is common. The reaction from developers and power users has been... less supportive.
This latest change sits at the center of a tension that has defined Android since its inception: how do you give users the freedom to install whatever they want while protecting the ones who don't know what they're doing? Android has been iterating on this question for 18 years, and the answer keeps changing.
A Brief History of Android App Installation
Early Android was essentially the Wild West. Any app could be installed from any source with a single tap. The 'Unknown Sources' toggle in settings was a global switch — turn it on, and every app on the device could install APKs. This was simple, user-empowering, and an absolute security nightmare.
Android 8 (Oreo, 2017) moved to per-source permissions. Instead of a global toggle, each app had to individually request the 'Install unknown apps' permission. Your browser could be allowed to install APKs while your email client couldn't. This was a genuine improvement — it contained the blast radius of a compromised app.
Android 13 added restricted settings. Sideloaded apps couldn't access certain sensitive APIs (accessibility services, notification listeners) without the user navigating through additional confirmation dialogs. The logic: apps from outside the Play Store haven't been vetted, so they shouldn't get easy access to the most powerful permissions.
Now, the 24-hour verification period adds another friction layer. Each iteration makes sideloading harder, and each iteration is justified by real security data. The question is whether the cumulative friction has crossed the line from 'protecting users' to 'coercing them into the Play Store.'
Why Sideloading Is a Real Security Problem
Before dismissing Google's concerns: sideloaded malware is a genuine, large-scale problem. Google's own data shows that apps installed from outside the Play Store are 50x more likely to contain malware than Play Store apps. In markets like Southeast Asia, where third-party app stores are popular, malware infection rates are significantly higher than in markets where Play Store usage dominates.
The attack vector is depressingly effective. A user receives a message — WhatsApp, SMS, email — with a link to download a 'bank security update' or 'phone cleaner' or 'free premium app.' They download the APK, dismiss the security warnings (because they've been trained to dismiss warnings), and install it. The malware gets accessibility service access (again, by convincing the user to grant it), and proceeds to steal banking credentials, intercept SMS verification codes, or encrypt the device for ransom.
These aren't sophisticated attacks. They work because social engineering is effective and because most users don't understand the risk model of installing arbitrary code. Google's position is that friction — making sideloading slower and more difficult — is the most effective defense because it creates time for the user to reconsider and for Google to scan the APK.
Why Developers Are Frustrated
The developer pushback isn't about malware. It's about control, distribution, and the growing friction of getting apps to users outside Google's ecosystem.
- Testing and development. Developers sideload constantly during development. A 24-hour wait for each test build is absurd. Google addresses this by exempting apps installed via ADB (Android Debug Bridge), but not all testing workflows use ADB — QA teams, beta testers, and client demos often use direct APK installs.
- Enterprise distribution. Companies that distribute internal apps outside the Play Store (managed via MDM solutions) face additional friction. While enterprise MDMs can bypass some restrictions, smaller organizations without MDM infrastructure are affected.
- Alternative app stores. F-Droid, Amazon Appstore, Samsung Galaxy Store — these legitimate distribution channels all involve sideloading from Google's perspective. Each additional restriction makes their user experience worse relative to the Play Store, which is exactly what critics accuse Google of wanting.
- Regulatory compliance. The EU's Digital Markets Act requires gatekeepers (including Google) to allow sideloading without undue friction. Making sideloading materially worse while technically keeping it possible is exactly the kind of compliance-theater the DMA was designed to prevent.
The Permission Model's Deeper Problems
Sideloading restrictions are a band-aid on a deeper problem: Android's permission model asks users to make security decisions they're not equipped to make. 'Allow this app to access your contacts?' 'Allow this app to read your SMS messages?' 'Allow this app to use accessibility services?' Most users don't understand the implications and either accept everything or deny everything.
The core issue: permissions are framed as binary choices about capabilities, when users think in terms of purposes. A user doesn't want to decide whether an app can read SMS messages. They want to decide whether the app can verify their phone number (reasonable) or intercept their bank's two-factor codes (not reasonable). Both require the same permission.
<!-- AndroidManifest.xml -->
<!-- Both of these use the same permission: -->
<uses-permission android:name="android.permission.READ_SMS" />
<!-- Use case 1: Auto-fill SMS verification code during signup -->
<!-- Perfectly legitimate, saves the user time -->
<!-- Use case 2: Intercept banking 2FA codes and forward to attacker -->
<!-- Malware, obviously -->
<!-- The permission system can't distinguish between these.
The user is asked to make a security decision that requires
understanding the app's implementation, which they can't see. -->iOS 'solved' this by not allowing sideloading at all (until regulatory pressure forced limited alternatives). That's a legitimate approach — remove the decision from users entirely — but it comes with its own costs: developer lock-in, App Store rent-seeking, and the inability to run software Apple hasn't approved.
What a Better System Might Look Like
Neither the iOS 'no sideloading' approach nor Android's 'sideloading with increasing friction' approach is ideal. A better system would need to address several things simultaneously.
- Risk-proportional friction. An app that requests no dangerous permissions and has been signed by a known developer should install instantly. An app that requests accessibility services, SMS access, and device admin permissions should face more scrutiny. The current system applies the same friction to a harmless open source calculator and a permission-hungry app requesting everything.
- Purpose-bound permissions. Instead of granting 'read SMS' broadly, grant 'read SMS for verification code auto-fill' — a scoped permission that can only be used in specific API contexts. Android has moved in this direction with the SMS Retriever API, but most permissions remain broadly scoped.
- Transparent scanning without waiting. Upload-and-scan is reasonable. A 24-hour wait is not, especially when most scans complete in minutes. Show users the scan result, let them proceed immediately if it's clean, and flag if the scan finds issues.
- First-party and third-party store parity. If the Play Store can install apps instantly, alternative stores should be able to as well — provided they implement equivalent security checks. The security argument only holds if the restrictions are about safety, not competitive advantage.
What Developers Should Do Now
Regardless of how you feel about Google's approach, the practical reality is that sideloading friction is increasing and unlikely to decrease. If you distribute apps outside the Play Store, plan for it.
- Use the Play App Signing program. Apps signed through Google's program may face less friction during sideloading verification because Google can verify the signature against known keys.
- For development, use ADB. ADB-installed apps bypass the 24-hour wait. Make sure your CI/CD pipelines and testing workflows use ADB rather than direct APK installation.
- Consider Progressive Web Apps. For apps that don't need deep platform integration, PWAs bypass the app store and sideloading question entirely. They install from the browser, update automatically, and don't require any special permissions to install.
- If you run an alternative store, implement robust scanning. Stores that demonstrate strong security practices may eventually get exemptions or reduced friction — the regulatory environment is pushing in that direction.
- Communicate delays to users. If your distribution relies on sideloading, warn users about the 24-hour wait upfront. An expected delay is less frustrating than a surprise one.
Android's openness was always a spectrum, not an absolute. Each version has shifted that spectrum slightly toward more control, justified by real security concerns and criticized for coinciding neatly with business interests. The 24-hour sideloading delay is the latest point on this trajectory — probably not the last. Whether you see it as reasonable protection or manufactured friction depends largely on where you think the balance should be between security and freedom. But the technical reality is clear: the days of frictionless sideloading on Android are over, and developers need to adapt their distribution strategies accordingly.