Let’s talk security: Answering your top questions about Android developer verification

Posted by Matthew Forsythe, Director, Product Management, Android App Safety

Android recently announced developer verification, an extra layer of security that deters bad actors and makes it harder for them to spread harm. 


Developer feedback is essential as we build this process. One of the most important themes we hear from the developer community is the need for more lead time to adapt to changes, which is why we announced this requirement more than a year before it takes effect. This extended timeline allows you to ask questions, provide feedback that will help shape the final process, and prepare for the new requirement, ensuring a smooth transition for your workflow. 


We're committed to answering your top questions, which you can find regularly updated in our guides and FAQ, and we've compiled the most frequent answers below. For a deeper discussion on developer identification, check out our conversation on Android Developer Backstage. 


Does this mean sideloading is going away on Android?

Absolutely not. Sideloading is fundamental to Android and it is not going away. Our new developer identity requirements are designed to protect users and developers from bad actors, not to limit choice. We want to make sure that if you download an app, it’s truly from the developer it claims to be published from, regardless of where you get the app. Verified developers will have the same freedom to distribute their apps directly to users through sideloading or through any app store they prefer.

How does developer verification impact my use of Android Studio?

We are working to ensure these changes don’t have an impact on your day-to-day workflow so you can continue building your apps as smoothly as possible. Participating in developer verification will not affect your experience in Android Studio, the official IDE for Android app development. You will continue to be able to build and run an app even if your identity is not verified. Android Studio is unaffected  because deployments performed with adb, which Android Studio uses behind the scenes to push builds to devices, is unaffected. You can continue to develop, debug, and test your app locally by deploying to both emulators and physical devices, just as you do now.

Making APKs available to your test team

If your team’s current test process relies on distributing APKs to testers for installation using methods other than adb, you will need to verify your identity and register the package. This also applies if you make APKs available to your test teams through Google Play Internal Testing, Firebase App Distribution, or similar solutions through other distribution partners.

Do I still need to register my apps if I’m only distributing to a limited number of users?

We recommend you register. It's a simple, one-time process that will allow anyone to download and install your app. However, if you prefer not to, we are also introducing a free developer account type that will allow teachers, students, and hobbyists to distribute apps to a limited number of devices without needing to provide a government ID.

If you’re interested in a limited distribution account, we want to hear from you to shape the experience.

What can I do to prepare for developer verification?

The best way to get ready and stay updated is to sign up for early access. We’ll start sending invitations in October.

We recommend you participate in developer verification because, even though verification is not required to develop apps with Android Studio, you will need it to distribute apps to certified Android devices. Apps installed through enterprise management tools on managed devices will also be installable without being registered.


Please let us know if you have any feedback or questions about the verification requirements.

Microsoft Teams Interoperability with Pexip Connect

What’s changing 

For more than seven years, Pexip has been a trusted interoperability partner for Google Meet, ensuring that participants can use their legacy meeting room systems to join Google Meet calls. We are excited to expand our relationship with Pexip Connect for Google Meet hardware – which will enable Google Meet hardware to seamlessly join Microsoft Teams from both Android and ChromeOS hardware. 

Additional Details 

  • There is an additional cost associated with using this offering from Pexip.
  • The integration supports joining scheduled meetings as well as joining with a meeting code 
  • Pexip enables Google Meet hardware to join Microsoft Teams meetings through their Pexip Connect service. Additional information can be found on their website. 

Getting started 

Pexip Connect for Google Meet hardware 

  • Admins 
    • Add the Pexip customer ID to the Built-in interoperability section of the Google Meet Hardware settings in the admin console. 
  • End users: 
    • When enabled by your admin, you can join a Teams meeting from a Google Meet hardware: 
      • Join an ad-hoc meeting by tapping "Join or start a meeting" on your touch controller (or on the touch screen device) and selecting Teams from the dropdown options. 
      • Add a a room to a with Teams meeting details. 
        • Note: Calendar events that originate outside of Google Calendar must be duplicated and populated with room details manually, or have their Teams meeting details copy and pasted into the description field of a new Calendar event. 
      • Visit the Help Center to learn more about Google Meet interoperability. 

Rollout pace 

Admin Setting 


End User Availability (on Devices) 


Availability 

  • Pexip Connect for Google Meet hardware is available to all Google Workspace customers, as well as G Suite Basic and Business customers with Google Meet hardware. All currently supported Google Meet hardware devices that have not yet reached their auto-update expiration date support the feature. 
  • Please work with either Pexip directly or an authorized reseller to get access 

Resources 



Google Mobile Ads Mediation adapters adopt Swift Package Manager

Today, we’re announcing you can start adding Google Mobile Ads mediation adapters to your iOS projects using Swift Package Manager (SPM).

Swift Package Manager is Apple's first-party tool for managing project dependencies. By supporting SPM, we're making it easier for you to integrate and manage our mediation adapters, helping you streamline your development workflow and reduce setup complexity.

Which adapters are supported?

We're planning to roll out SPM support for all open source and versioned adapters. Each adapter will be in its own dedicated GitHub repository.

Adapters currently available:

Ad source Minimum version supported in SPM
AppLovin 13.3.1.0
DT Exchange 8.3.8.0
IronSource 8.10.0.0
Liftoff Monetize 7.5.3.0
i-mobile 2.3.4.2
inMobi 10.8.6.0
Meta 6.20.1.0
Mintegral 7.7.9.0
Pangle 7.4.1.1.0
Unity 4.16.0.0

Add a Swift Package to your project

To add a package dependency to your Xcode project, navigate to File > Add Package Dependencies… and search for the package using each adapter's corresponding GitHub URL:

Adapters coming soon

We're continuing to roll out Swift Package Manager support for more mediation adapters. Check the list of currently supported adapters by visiting our GitHub page.

If you have any questions or want to discuss this post, please reach out to us on our “Google Advertising and Measurement Community” Discord server.

 - Justin Malandruccolo, Mobile Ads Developer Relations

Ransomware detection and file restoration for Google Drive available in beta

What’s changing 

We’re adding two new features to help organizations minimize the impact of ransomware attacks on personal computers. Specifically, we are adding these features in beta: 

  • Ransomware detection: When users have Google Drive for desktop installed on their computers, file syncing will be paused when ransomware is detected. The user will see a notification appear on their computer. Admins will see an alert in the Admin console security center. And notification emails will be delivered to both users and admins. 
  • File restoration: Users are able to restore their files to a previous version in Drive with ease, saving them time and money without paying a ransom. Users can select and restore multiple files prior to when ransomware infected their computer, making their files inaccessible. 


Getting started 

Admins: 

  • Ransomware detection will be on by default for users in your organization. You can turn it on or off at the OU level by going to Admin console > Apps > Google Workspace > Settings for Drive and Docs > Malware and Ransomware. If ransomware is detected for your users, admins will receive an email and get an alert in the Alert center. 
  • Drive file restoration will be on by default. You can turn it on or off at Admin console > Apps > Google Workspace > Settings for Drive and Docs > Drive file restoration. 
  • Visit the Help Center to learn more about managing ransomware detection and file restoration for your organization. 
The Admin console setting for ransomware detection 

The Admin console setting for Drive file restoration 


Email to admins when potential ransomware is detected 


Admin alert in the Alert center with information on the potential ransomware detection 


Alert detail on the ransomware detection 

End users: 

  • The availability of this feature will depend on your admin’s settings. If turned on and ransomware is detected, you will see the alerts and access the interface below. 
  • Use the Help Center to learn more about restoring files in bulk with Google Drive. 

End user alert in Drive for desktop when ransomware is detected 


Interface to assist with file recovery 

Rollout pace 

Admin console setting 


File detection and restoration features 


Availability 

File restoration 

  • Available to all Google Workspace customers, Workspace Individual Subscribers, and users with personal Google accounts 

Ransomware detection 

Available for Google Workspace: 

  • Business Standard, Plus 
  • Enterprise Starter, Standard, Plus 
  • Education Standard and Plus 
  • Frontline Standard and Plus 

Resources 


Meet eCDN custom rules improvements for new and existing configurations

What's changing 

In order to improve the experience of admins managing Google Meet’s Enterprise Content Delivery Network (Meet eCDN) rules, we’re updating how the “Custom Rules” peering policy works in some cases, and how assigned networks are surfaced in the MQT eCDN network table. Understanding these changes will allow customers to make full use of those improvements. 


Overlapping IP ranges 

Please note you will only see this change if you have defined overlapping IP ranges. For example, if you have defined a large range that’s allowed but including some smaller ranges that should be blocked within it. If you have non-overlapping ranges only, you won’t be affected by this change. 

Viewers with the “custom rules” peering policy will be matched against a list of IP ranges and their respective peering configuration (allowed or blocked). This is done by checking all listed ranges in order from top to bottom. Previously, any blocking match would supersede an allowing match, even if the allowing match came first. We’re removing the priority for blocking changes to simplify how matches are determined. 

Example for a viewer with private IP address 10.0.0.30: 

Scenario 1:

Viewer 1 private IP: 10.0.0.30
Viewer 2 private IP: 11.0.0.30

Custom rules list:
  • 10.0.0.0 - 10.0.0.255: allowed
  • 11.0.0.0 - 11.0.0.255: blocked
Fallback policy: blocked

Before:
  • Viewer 1 allowed since one allowed match
  • Viewer 2 blocked since one blocked match

After:
  • Same results, no changes in this scenario, since there are no overlapping IP ranges.

Scenario 2:

Viewer 1 private IP: 10.0.0.30
Viewer 2 private IP: 11.0.0.30

Custom rules list:
  • 10.0.0.0 - 10.0.0.255: allowed
  • 10.0.0.0 - 15.0.0.0: blocked
Fallback policy: blocked

Before:
  • Viewer 1 blocked, since one allowed and one blocked match, and blocked matches have higher priority.
  • Viewer 2 blocked, since one blocked match.

After:
  • Viewer 1 allowed, since the first match encountered (top to bottom) was to allow the IP.
  • Viewer 2 blocked, since the only matching rule was blocking the IP.

Scenario 3:

  • Viewer 1 private IP: 10.0.0.30
  • Viewer 2 private IP: 11.0.0.30

Custom rules list:
  • 10.0.0.0 - 15.0.0.0: blocked
  • 10.0.0.0 - 10.0.0.255: allowed
Fallback policy: blocked

Before:
  • Viewer 1 blocked, since one allowed and one blocked match, and blocked matches have higher priority.
  • Viewer 2 blocked, since one blocked match.

After:
  • Viewer 1 blocked, since the first match encountered (top to bottom) was to block the IP.
  • Viewer 2 blocked, since the only matching rule was blocking the IP.
Please note that smaller IP ranges should be listed before large ranges containing them (top-to-bottom).





Multiple private IP addresses are now supported 
Please note that the following change will only materialize if your viewers’ devices have multiple private IP addresses configured on their network interfaces (typically one IPv4 and one IPv6 address). 

Previously, eCDN clients would detect their private IP address and always prioritize IPv4 over IPv6. Also, only a single IP address could be detected and sent for matching against custom rules. We’re changing this so that all private IPs configured on the device’s interfaces will be used for matching. To ensure top-to-bottom evaluation, the first rule matching any detected private IP addresses will be used. 


Renaming Random peering policy 
The policy previously called Random peering policy is now called Testing peering policy. This policy is primarily intended for test purposes and is not designed to provide full performance in production. 


Meet Quality Tool improvements 
Viewers with the Testing peering policy will now be represented in the Meet Quality Tool eCDN table. Previously this table would only show viewers per configured network if the Custom Rules peering policy was used. 

Rollout pace: 

  • Rapid Release domains: Gradual rollout (up to 15 days for feature visibility) starting on October 6, 2025. 
  • Scheduled release domains: Gradual rollout (up to 15 days for feature visibility) starting on October 28, 2025. 

Resources: 



Improve Chat apps with display carousels and richer text formatting

What’s changing 

Developers can use two new features to create more engaging Chat apps. Specifically, we are adding: 
  • A carousel widget: With this new carousel widget, you'll be able to interact with more complex and organized information in a horizontally scrollable carousel. 
  • Markdown support: The new Markdown support for text formatting will allow developers to specify markdown instead of converting all text to HTML. 
  • Lists and code blocks: You’ll now be able to add ordered, unordered, and nested lists, and code blocks to cards. 

Why you’d use it: 

The carousel widget provides a powerful tool for presenting complex information in an organized, scrollable, and compact format. Developers can use it to display product listings, multiple data points, or different options within a single card, creating a much more efficient and professional-looking user experience. 

Markdown support can help simplify the process to build cards, and is especially critical to developers who are building AI agents. The standard output from many LLMs is markdown. Now, instead of converting the markdown to HTML, developers can now pass the entire markdown to Chat which will handle and render the text correctly. 

Lists and code blocks are essential building blocks to enable rich display of information, enhancing readability and comprehension for users. They unlock critical use cases, such as providing structured data, displaying programming examples, and organizing complex details. 



The carousel widget enables scrolling through information in an efficient and engaging manner 


Markdown support enables easier to use text formatting while list and code block support enables richer text format 

Getting started 

  • Developers: See our documentation to learn more about adding carousels or formatting messages. 
  • Admins: There is no admin control for this feature. It will be available by default when Developers choose to use it in their apps. Use our Help Center to learn more about allowing users to install Chat apps. 
  • End users: There is no end user control for this feature. It will be available by default when Developers choose to use it in their apps. Use our Help Center to learn more about Chat apps. 

Rollout pace 

  • This feature is available now. 

Availability 

  • Available to all Google Workspace customers 

Resources