Posted by Suzanne Frey – VP, Product, Trust & Growth for Android

You shouldn’t have to choose between open and secure. By engineering security into the core part of the OS, Android has proven that you can have both, and we continue taking new steps in that direction.

As new threats emerge, we’ve continued to evolve our defenses. Following recent attacks, including those targeting people’s financial data on their phones, we’ve worked to increase developer accountability to prevent abuse. We’ve seen how malicious actors hide behind anonymity to harm users by impersonating developers and using their brand image to create convincing fake apps. The scale of this threat is significant: our recent analysis found over 50 times more malware from internet-sideloaded sources than on apps available through Google Play.

To better protect users from repeat bad actors spreading malware and scams, we’re adding another layer of security to make installing apps safer for everyone: developer verification.

Starting next year, Android will require all apps to be registered by verified developers in order to be installed by users on certified Android devices. This creates crucial accountability, making it much harder for malicious actors to quickly distribute another harmful app after we take the first one down. Think of it like an ID check at the airport, which confirms a traveler’s identity but is separate from the security screening of their bags; we will be confirming who the developer is, not reviewing the content of their app or where it came from. This change will start in a few select countries specifically impacted by these forms of fraudulent app scams, often from repeat perpetrators.

Since we implemented verification requirements on Google Play in 2023, we have seen firsthand how helpful developer identification is in stopping bad actors from exploiting anonymity to distribute malware, commit financial fraud, and steal sensitive data. Bringing a similar process to Android more broadly will provide a consistent, common sense baseline of developer accountability across the ecosystem.

In early discussions about this initiative, we’ve been encouraged by the supportive initial feedback we’ve received. In Brazil, the Brazilian Federation of Banks (FEBRABAN) sees it as a “significant advancement in protecting users and encouraging accountability.” This support extends to governments as well, with Indonesia’s Ministry of Communications and Digital Affairs praising it for providing a “balanced approach” that protects users while keeping Android open. Similarly, Thailand’s Ministry of Digital Economy and Society sees it as a “positive and proactive measure” that aligns with their national digital safety policies. And partners like the Developer’s Alliance have called this a “critical step” for ensuring “trust, accountability, and security” across the entire ecosystem.

To make this process as streamlined as possible, we are building a new Android Developer Console just for developers who only distribute outside of Google Play, so they can easily complete their verification; get an early look at how it works. A note for student and hobbyist developers: we know your needs are different from commercial developers, so we’re creating a separate type of Android Developer Console account for you.

If you distribute apps on Google Play, you’ve likely already met these verification requirements through the existing Play Console process. You can find more information about how these requirements apply to you in our guides.

To be clear, developers will have the same freedom to distribute their apps directly to users through sideloading or to use any app store they prefer. We believe this is how an open system should work—by preserving choice while enhancing security for everyone. Android continues to show that with the right design and security principles, open and secure can go hand in hand. For more details on the specific requirements, visit our website. We’ll share more information in the coming months.

Timeline and how to prepare

To help you get ready, we encourage all developers who distribute apps on certified Android devices to sign up for early access. This is the best way to prepare and stay informed.

Early participants will also get:

• An invitation to an exclusive community discussion forum.
• Priority support for these new requirements.
• The chance to provide feedback and help us shape the experience.

Sign up for early access now

Here is the timeline to help you plan:

• October 2025: Early access begins. Invitations will be sent out gradually.
• March 2026: Verification opens for all developers.
• September 2026: These requirements go into effect in Brazil, Indonesia, Singapore, and Thailand. At this point, any app installed on a certified Android device in these regions must be registered by a verified developer.
• 2027 and beyond: We will continue to roll out these requirements globally.

Posted by Naheed Vora – Senior Product Manager, Android App Safety

Making it easier for you to build safer apps from the start

We understand you want clear Play policy guidance early in your development, so you can focus on building amazing experiences and prevent unexpected delays from disrupting launch plans. That’s why we’re making it easier to have smoother app publishing experiences, from the moment you start coding.

With Play Policy Insights beta in Android Studio, you’ll get richer, in-context guidance on policies that may impact your app through lint warnings. You’ll see policy summaries, dos and don’ts to avoid common pitfalls, and direct links to details.

We hope you caught an early demo at I/O. And now, you can check out Play Policy Insights beta in the Android Studio Narwhal Feature Drop Canary release.

How to use Play Policy Insights beta in Android Studio

Lint warnings will pop up as you code, like when you add a permission. For example, if you add an Android API that uses Photos and requires READ_MEDIA_IMAGES permission, then the Photos & Video Insights lint warning will appear under the respective API call line item in Android Studio.

You can also get these insights by going to Code > Inspect for Play Policy Insights and selecting the project scope to analyze. The scope can be set to the whole project, the current module or file, or a custom scope.

In addition to seeing these insights in Android Studio, you can also generate them as part of your Continuous Integration process by adding the following dependency to your project.

Kotlin

lintChecks("com.google.play.policy.insights:insights-lint:<version>")

Groovy

lintChecks 'com.google.play.policy.insights:insights-lint:<version>'

Share your feedback on Play Policy Insights beta

We’re actively working on this feature and want your feedback to refine it before releasing it in the Stable channel of Android Studio later this year. Try it out, report issues, and stop by the Google Play Developer Help Community to share your questions and thoughts directly with our team.

Join us on June 16 when we answer your questions. We’d love to hear about:

• How will this change your current Android app development and Google Play Store submission workflow?
• Which was more helpful in addressing issues: lint warnings in the IDE or lint warnings from CI build?
• What was most helpful in the policy guidance, and what could be improved?

Developers have told us they like:

• Catching potential Google Play policy issues early, right in their code, so they can build more efficiently.
• Seeing potential Google Play policy issues and guidance all in one-place, reducing the need to dig through policy announcements and issue emails.
• Easily discussing potential issues with their team, now that everyone has shared information.
• Continuously checking for potential policy issues as they add new features, gaining confidence in a smoother launch.

For more, see our Google Play Help Center article or Android Studio preview release notes.

We hope features like this will help give you a better policy experience and more streamlined development.

Posted by Dan Brown – Product Manager, Google Play

Google Play empowers you to manage and distribute your innovative and trusted apps and games to billions of users around the world across the entire breadth of Android devices, and historically, all Android devices have managed memory in 4 KB pages.

As device manufacturers equip devices with more RAM to optimize performance, many will adopt larger page sizes like 16 KB. Android 15 introduces support for the increased page size, ensuring your app can run on these evolving devices and benefit from the associated performance gains.

Starting November 1st, 2025, all new apps and updates to existing apps submitted to Google Play and targeting Android 15+ devices must support 16 KB page sizes.

This is a key technical requirement to ensure your users can benefit from the performance enhancements on newer devices and prepares your apps for the platform’s future direction of improved performance on newer hardware. Without recompiling to support 16 KB pages, your app might not function correctly on these devices when they become more widely available in future Android releases.

We’ve seen that 16 KB can help with:

• Faster app launches: See improvements ranging from 3% to 30% for various apps.
• Improved battery usage: Experience an average gain of 4.5%.
• Quicker camera starts: Launch the camera 4.5% to 6.6% faster.
• Speedier system boot-ups: Boot Android devices approximately 8% faster.

We recommend checking your apps early especially for dependencies that might not yet be 16 KB compatible. Many popular SDK providers, like React Native and Flutter, already offer compatible versions. For game developers, several leading game engines, such as Unity, support 16 KB, with support for Unreal Engine coming soon.

Reaching 16 KB compatibility

A substantial number of apps are already compatible, so your app may already work seamlessly with this requirement. For most of those that need to make adjustments, we expect the changes to be minimal.

• Apps with no native code should be compatible without any changes at all.
• Apps using libraries or SDKs that contain native code may need to update these to a compatible version.
• Apps with native code may need to recompile with a more recent toolchain and check for any code with incompatible low level memory management.

Our December blog post, Get your apps ready for 16 KB page size devices, provides a more detailed technical explanation and guidance on how to prepare your apps.

Check your app’s compatibility now

It’s easy to see if your app bundle already supports 16 KB memory page sizes. Visit the app bundle explorer page in Play Console to check your app’s build compliance and get guidance on where your app may need updating.

Beyond the app bundle explorer, make sure to also test your app in a 16 KB environment. This will help you ensure users don’t experience any issues and that your app delivers its best performance.

For more information, check out the full documentation.

Thank you for your continued support in bringing delightful, fast, and high-performance experiences to users across the breadth of devices Play supports. We look forward to seeing the enhanced experiences you’ll deliver with 16 KB support.