Android developers distributing their applications through third-party app stores will soon face new identity verification requirements from Google. This initiative, aimed at enhancing security measures around sideloading apps, will begin in September 2026 for developers in Brazil, Indonesia, Singapore, and Thailand, with a global rollout anticipated in 2027 and beyond.
Under these new guidelines, developers will be required to submit personal information to Google, including their legal name, address, email, and phone number. In some cases, they may also need to provide an official government-issued ID. While identity verification is already a standard procedure for those using the Google Play Store, this change primarily affects developers who operate exclusively outside of this platform.
Google emphasized that this step is part of its broader commitment to creating a safer Android environment. “By making Android safer, we’re protecting the open environment that allows developers and users to confidently create and connect,” the company stated. The new verification process is designed to deter malicious actors and reduce the risk of malware and scams for users who download apps from outside the Play Store.
This move aligns with similar actions taken by Apple, which introduced developer verification requirements for the EU App Store earlier this year to comply with the Digital Services Act (DSA). This legislation mandates that online platforms verify the identities of “traders” who offer products and services to consumers within the EU.
Google’s focus appears to be on commercial developers, while still maintaining an open platform for student and hobbyist developers. To support this, the company plans to create a separate Android developer console that will impose restrictions on the number of apps and installations for those less commercially oriented developers.
In an effort to refine the new verification process, Google is inviting developers to sign up for early access to the rules, encouraging them to provide feedback that could influence the final implementation. This proactive approach suggests that the requirements may evolve before their official launch, allowing for adjustments based on developer input.
