On August 18, Google announced that it is gradually rolling out the initial version of "Advanced Flow," a new process for installing or updating apps from unverified developers on Android. This is not a blanket measure to block app sideloading. Apps distributed by registered developers can still be installed as before, but for unverified apps, Google has introduced a path that requires users to change a setting themselves and then wait 24 hours.
Previously, allowing apps from unknown sources on Android did not involve a one-day waiting period tied to developer identity verification. What Google has changed is not whether APKs can be handled at all, but rather the default setting determining whose apps can be installed through the ordinary flow. While the measure aims to counter fraud, it also adds extra steps specifically for distributors and users who have not registered with Google.
The rollout of the initial version, the scope of its September 30 application, and the full global deployment planned for 2027 are three distinct developments. Viewed separately, the debate over Android's openness is shifting from "whether sideloading is possible" to whether the exception pathway is something ordinary users can realistically use.
The 24-Hour Wait Applies to the Exception Path for Unverified Apps
Advanced Flow is required when installing or updating an unverified app without using ADB. It is not required for registered apps, regardless of whether they come from an app store or a website. The same applies to apps delivered via messaging apps or file hosting services. Apps under limited distribution and installations via ADB are also excluded.
To enable it, users go to Developer Options and select "Apps from unverified developers," then authenticate with their screen lock. After confirming that no one is instructing them through the process, they restart the device. Following the restart, after waiting 24 hours, users can choose to enable the setting for either 7 days or indefinitely. This is not a system requiring a one-day wait for every single APK, but rather a wait tied to unlocking the setting that allows apps from unverified developers to be accepted.
Even after enabling the setting, installing or updating an unverified app still triggers a warning, though users can select "Install anyway." If the feature is disabled and then re-enabled within 10 minutes, the 24-hour wait does not need to be repeated. However, if more than 10 minutes have passed before re-enabling it, the 24-hour wait applies again. ADB handling remains unchanged, and there is no need to keep Developer Options enabled after completing the Advanced Flow setup. Read only as a headline, this could look like a "sideloading restriction," but in practice it is a design that separates the standard pathway from one that requires deliberate, conscious action.
September 30 Rollout Begins With 4 Countries and 7 Stores
According to the plan Google announced in June, initial developer verification will apply starting September 30 in Brazil, Indonesia, Singapore, and Thailand. The seven stores named are Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore, and GetApps. As of September, direct sideloading and stores outside these seven are not covered.
Therefore, the August rollout of Advanced Flow should not be treated as an event where the same restrictions apply worldwide to all APKs starting at the end of September. Google has stated plans for global deployment by 2027 for certified Android devices, but has not disclosed a country-by-country timeline or how final enforcement will work across all distribution channels. The number of devices reached and the models covered by the initial version also remain undisclosed.
The Android Developer Verifier responsible for verification is a Google system service distributed separately from major OS updates. According to Google's explanation, it checks whether an app is registered to a verified developer. Since the feature can arrive without waiting for a major OS update, it is necessary to track the scope of institutional application separately from the behavior actually displayed on devices.
What Developer Verification Covers
Under a full-distribution Android Developer Console account, developers link real identity information to a package name and signing key. The account fee is $25, and depending on the case, individuals may be required to submit a government-issued ID, while organizations may need a D-U-N-S number along with identity and organizational verification documents. As of June, Google stated that registered apps cover nearly all installations on Google Play and the majority outside of Play, with over 99% of Play apps being registered. However, the denominator for this percentage was not disclosed on the same page.
Smaller-scale distributors have another option. Limited distribution requires neither a fee nor submission of a government-issued ID, places no cap on the number of apps, and allows distribution to up to 20 authorized devices. This option suits student projects, personal development, or sharing apps with acquaintances, under different conditions than full distribution.
This creates three paths for developers. To distribute broadly, developers can undergo identity verification and choose full distribution. For sharing only with a closed group, they can use limited distribution capped at 20 devices. If they choose to avoid identity verification and distribute without registering, recipients must use either ADB or Advanced Flow. Developers who want to reach general users beyond 20 devices face a difficult choice: register with Google, or require every individual user to configure an exception setting.
What is being verified here is the developer's identity, not a review of the app's content. Being registered does not guarantee an app is free of malicious intent, nor does being unregistered mean it is dangerous. Still, linking a package name and signing key to a real entity raises the cost of re-distributing under a different name after removal. What Google is trying to increase is not a substitute for malware screening, but distributor accountability.
The Restart and Wait Target Fraud That Relies on Urgency
Google explains the restart and 24-hour wait as a countermeasure against fraud schemes that pressure users during a phone call or remote-access session. If an attacker is guiding a user through settings over a screen-sharing session, the restart cuts off the ongoing session, and the wait removes the time pressure of "install it right now." This is also why the wait is tied to enabling the exception setting rather than to each individual APK.
However, this defense is effective specifically against attacks that lure users into the unverified-app pathway. It is not a mechanism that guarantees the safety of registered apps, nor does it substitute for code review or malware screening. Treating developer identity verification and content review as the same thing risks confusing the risk the system actually mitigates with the risk that remains.
At the same time, the added friction falls on both developers and users. Returning to the standard distribution path requires Google identity verification and registration, while users who deliberately choose to use an unverified app must accept the burden of changing settings, restarting, and waiting. Being technically able to install something and being able to easily choose to do so in daily use have become two separate conditions.
What the EU Is Watching: The Balance Between Openness and Integrity Measures
On April 8, the European Commission explained that under Article 6(4) of the Digital Markets Act (DMA), gatekeepers must enable effective distribution through third-party stores and the web. At the same time, the Commission stated that it permits integrity protection measures that are strictly necessary and proportionate, where justified. The Commission continues its regulatory dialogue with Alphabet and is monitoring the developer verification program.
At this point, the EU has not ruled the program either lawful or unlawful. Moreover, none of the four countries in the initial September 30 rollout are EU member states. There is no basis for treating an eventual EU assessment as a preemptive conclusion about the program's near-term rollout.
What should be confirmed at the end of September is how developer verification actually appears on users' screens across the seven stores. For the 2027 global rollout, questions remain regarding final behavior across all distribution channels including direct distribution, country-specific timelines, and mechanisms for appeals or error handling. Whether the claim of preserving sideloading holds real substance will be determined not by whether an exception pathway exists, but by whether its conditions are something developers and users can actually bear.