Our Taipei office will be Google’s largest AI infrastructure hardware engineering center outside of the U.S.
Following the Query groups launch last month, we're happy to announce we're providing an additional tool to analyze the performance of your website by query type in the Search Console Performance Report: the branded queries filter. This new feature is designed to help analyze the queries driving traffic to your site by automatically differentiating between branded and non-branded queries.
We're pleased to announce that v202511 of the Google Ad Manager API is available now. This release provides support for targeting Publisher Provided Signals using PublisherProvidedSignalsTargeting. You can also check the declaration status of Ad technology providers using ThirdPartyDataDeclarationStatus on Creatives, and read the verifiedExchangeAdvertiserdId on Companies.
For the full list of changes, check the release notes. Contact us on the Ad Manager API forum with any API-related questions.
- Chris Seeley, Ad Manager API Team
Jetpack Navigation 3 version 1.0 is stable 🎉. Go ahead and use it in your production apps today. JetBrains are already using it in their KotlinConf app.
Navigation 3 is a new navigation library built from the ground up to embrace Jetpack Compose state. It gives you full control over your back stack, helps you retain navigation state, and allows you to easily create adaptive layouts (like list-detail). There's even a cross-platform version from JetBrains.
Why a new library?
The original Jetpack Navigation library (now Nav2) was designed 7 years ago and, while it serves its original goals well and has been improved iteratively, the way apps are now built has fundamentally changed.
Reactive programming with a declarative UI is now the norm. Nav3 embraces this approach. For example, NavDisplay (the Nav3 UI component that displays your screens) simply observes a list of keys (each one representing a screen) backed by Compose state and updates its UI when that list changes.
Figure 1. NavDisplay observes changes to a list backed by Compose state.
Nav2 can also make it difficult to have a single source of truth for your navigation state because it has its own internal state. With Nav3, you supply your own state, which gives you complete control.
Lastly, you asked for more flexibility and customizability. Rather than having a single, monolithic API, Nav3 provides smaller, decoupled APIs (or "building blocks") that can be combined together to create complex functionality. Nav3 itself uses these building blocks to provide sensible defaults for well-defined navigation use cases.
This approach allows you to:
Customize screen animations at both a global and individual level
Display multiple panes at the same time, and create flexible layouts using the Scenes API
Easily replace Nav3 components with your own implementations if you want custom behavior
Read more about its design and features in the launch blog.
Migrating from Navigation 2
If you're already using Nav2, specifically Navigation Compose, you should consider migrating to Nav3. To assist you with this, there is a migration guide. The key steps are:
Add the navigation 3 dependencies.
Update your navigation routes to implement NavKey. Your routes don't have to implement this interface to use Nav3, but if they do, you can take advantage of Nav3's rememberNavBackStack function to create a persistent back stack.
Create classes to hold and modify your navigation state - this is where your back stacks are held.
Replace NavController with these classes.
Move your destinations from NavHost's NavGraph into an entryProvider.
Replace NavHost with NavDisplay.
Experimenting with AI agent migration
You may want to experiment with using an AI agent to read the migration guide and perform the steps on your project. To try this with Gemini in Android Studio's Agent Mode:
Save this markdown version of the guide into your project.
Paste this prompt to the agent (but don't hit enter): "Migrate this project to Navigation 3 using ".
Type @migration-guide.md - this will supply the guide as context to the agent.
As always, make sure you carefully review the changes made by the AI agent - it can make mistakes!
We'd love to hear how you or your agent performed, please send your feedback here.
Tasty navigation recipes for common scenarios
For common but nuanced use cases, we have a recipes repository. This shows how to combine the Nav3 APIs in a particular way, allowing you to choose or modify the recipe to your particular needs. If a recipe turns out to be popular, we'll consider "graduating" the non-nuanced parts of it into the core Nav3 library or add-on libraries.
Figure 2. Useful code recipes can graduate into a library.
There are currently 19 recipes, including for:
Passing navigation arguments to ViewModels (including using Koin)
Returning results from screens by events and by shared state
We're currently working on a deeplinks recipe, plus a Koin integration, and have plenty of others planned. An engineer from JetBrains has also published a Compose Multiplatform version of the recipes.
If you have a common use case that you'd like to see a recipe for, please file a recipe request.
Summary
To get started with Nav3, check out the docs and the recipes. Plus, keep an eye out for a whole week of technical content including:
A deep dive video on the API covering modularization, animations and adaptive layouts.
A live Ask Me Anything (AMA) with the engineers who built Nav3.
Nav3 Spotlight Week starts Dec 1st 2025.
Jetpack Navigation 3 version 1.0 is stable 🎉. Go ahead and use it in your production apps today. JetBrains are already using it in their KotlinConf app.
Navigation 3 is a new navigation library built from the ground up to embrace Jetpack Compose state. It gives you full control over your back stack, helps you retain navigation state, and allows you to easily create adaptive layouts (like list-detail). There's even a cross-platform version from JetBrains.
Why a new library?
The original Jetpack Navigation library (now Nav2) was designed 7 years ago and, while it serves its original goals well and has been improved iteratively, the way apps are now built has fundamentally changed.
Reactive programming with a declarative UI is now the norm. Nav3 embraces this approach. For example, NavDisplay (the Nav3 UI component that displays your screens) simply observes a list of keys (each one representing a screen) backed by Compose state and updates its UI when that list changes.
Figure 1. NavDisplay observes changes to a list backed by Compose state.
Nav2 can also make it difficult to have a single source of truth for your navigation state because it has its own internal state. With Nav3, you supply your own state, which gives you complete control.
Lastly, you asked for more flexibility and customizability. Rather than having a single, monolithic API, Nav3 provides smaller, decoupled APIs (or "building blocks") that can be combined together to create complex functionality. Nav3 itself uses these building blocks to provide sensible defaults for well-defined navigation use cases.
This approach allows you to:
Customize screen animations at both a global and individual level
Display multiple panes at the same time, and create flexible layouts using the Scenes API
Easily replace Nav3 components with your own implementations if you want custom behavior
Read more about its design and features in the launch blog.
Migrating from Navigation 2
If you're already using Nav2, specifically Navigation Compose, you should consider migrating to Nav3. To assist you with this, there is a migration guide. The key steps are:
Add the navigation 3 dependencies.
Update your navigation routes to implement NavKey. Your routes don't have to implement this interface to use Nav3, but if they do, you can take advantage of Nav3's rememberNavBackStack function to create a persistent back stack.
Create classes to hold and modify your navigation state - this is where your back stacks are held.
Replace NavController with these classes.
Move your destinations from NavHost's NavGraph into an entryProvider.
Replace NavHost with NavDisplay.
Experimenting with AI agent migration
You may want to experiment with using an AI agent to read the migration guide and perform the steps on your project. To try this with Gemini in Android Studio's Agent Mode:
Save this markdown version of the guide into your project.
Paste this prompt to the agent (but don't hit enter): "Migrate this project to Navigation 3 using ".
Type @migration-guide.md - this will supply the guide as context to the agent.
As always, make sure you carefully review the changes made by the AI agent - it can make mistakes!
We'd love to hear how you or your agent performed, please send your feedback here.
Tasty navigation recipes for common scenarios
For common but nuanced use cases, we have a recipes repository. This shows how to combine the Nav3 APIs in a particular way, allowing you to choose or modify the recipe to your particular needs. If a recipe turns out to be popular, we'll consider "graduating" the non-nuanced parts of it into the core Nav3 library or add-on libraries.
Figure 2. Useful code recipes can graduate into a library.
There are currently 19 recipes, including for:
Passing navigation arguments to ViewModels (including using Koin)
Returning results from screens by events and by shared state
We're currently working on a deeplinks recipe, plus a Koin integration, and have plenty of others planned. An engineer from JetBrains has also published a Compose Multiplatform version of the recipes.
If you have a common use case that you'd like to see a recipe for, please file a recipe request.
Summary
To get started with Nav3, check out the docs and the recipes. Plus, keep an eye out for a whole week of technical content including:
A deep dive video on the API covering modularization, animations and adaptive layouts.
A live Ask Me Anything (AMA) with the engineers who built Nav3.
Nav3 Spotlight Week starts Dec 1st 2025.
To create a more consistent and secure meeting experience, we're changing what happens when you edit recurring Google Calendar events. Previously, when users modified the start time or recurrence of recurring events and applied the change to "This and following events," the remaining events used the original Google Meet link.
Moving forward, when users modify the start time or recurrence of a recurring event for "This and following events," the remaining events will automatically generate a new, unique Meet link. The original event series will keep the original Meet link. All properties of the Meet conference (for example the host, cohosts, access restriction, recording) are preserved for both Meet links.
This change ensures each new recurring event series gets its own distinct and secure Meet link, which prevents the unintentional reuse of meeting links across separate Calendar events. This is one of multiple updates we’re making to create a more reliable experience for using Meet with Calendar events.
Available to all Google Workspace customers and users with personal Google accounts
In the mobile ecosystem, abuse can threaten your revenue, growth, and user trust. To help developers thrive, Google Play offers a resilient threat detection service, Play Integrity API. Play Integrity API helps you verify that interactions and server requests are genuine—coming from your unmodified app on a certified Android device, installed by Google Play.
The impact is significant: apps using Play integrity features see 80% lower unauthorized usage on average compared to other apps. Today, leaders across diverse categories—including Uber, TikTok, Stripe, Kabam, Wooga, Radar.com, Zimperium, Paytm, and Remini—use it to help safeguard their businesses.
We’re continuing to improve the Play Integrity API, making it easier to integrate, more resilient against sophisticated attacks, and better at recovering users who don’t meet integrity standards or encounter errors with new Play in-app remediation prompts.
The Play Integrity API offers verdicts designed to detect specific threats that impact your bottom line during critical interactions.
Unauthorized access: The accountDetails verdict helps you determine whether the user installed or paid for your app or game on Google Play.
Code tampering: The appIntegrity verdict helps you determine whether you're interacting with your unmodified binary that Google Play recognizes.
Risky devices and emulated environments: The deviceIntegrity verdict helps you determine whether your app is running on a genuine Play Protect certified Android device or a genuine instance of Google Play Games for PC.
Unpatched devices: For devices running Android 13 and higher, MEETS_STRONG_INTEGRITY response in the deviceIntegrity verdict helps you determine if a device has applied recent security updates. You can also opt in to deviceAttributes to include the attested Android SDK version in the response.
Risky access by other apps: The appAccessRiskVerdict helps you determine whether apps are running that could be used to capture the screen, display overlays, or control the device (for example, by misusing the accessibility permission). This verdict automatically excludes apps that serve genuine accessibility purposes.
Known malware: The playProtectVerdict helps you determine whether Google Play Protect is turned on and whether it has found risky or dangerous apps installed on the device.
Hyperactivity: The recentDeviceActivity level helps you determine whether a device has made an anomalously high volume of integrity token requests recently, which could indicate automated traffic and could be a sign of attack.
Repeat abuse and reused devices: deviceRecall (beta) helps you determine whether you're interacting with a device that you've previously flagged, even if your app was reinstalled or the device was reset. With device recall, you can customize the repeat actions you want to track.
The API can be used across Android form factors including phones, tablets, foldables, Android Auto, Android TV, Android XR, ChromeOS, Wear OS, and on Google Play Games for PC.
Apps and games have found success with the Play Integrity API by following the security considerations and taking a phased approach to their anti-abuse strategy.
Step 1: Decide what you want to protect: Decide what actions and server requests in your apps and games are important to verify and protect. For example, you could perform integrity checks when a user is launching the app, signing in, joining a multiplayer game, generating AI content, or transferring money.
Deciding how to respond to different integrity signals can be complex, you need to handle various integrity responses and API error codes (like network issues or outdated Play services). We’re simplifying this with new Play in-app remediation prompts. You can show a Google Play prompt to your users to automatically fix a wide range of issues directly within your app. This reduces integration complexity, ensures a consistent user interface, and helps get more users back to a good state.
GET_INTEGRITY automatically detects the issue
(in this example, a network error)
and resolves it.
You can trigger the GET_INTEGRITY dialog, available in Play Integrity API library version 1.5.0+, after a range of issues to automatically guide the user through the necessary fixes including:
Unauthorized access: GET_INTEGRITY guides the user back to a Play licensed response in accountDetails.
Code tampering: GET_INTEGRITY guides the user back to a Play recognized response in appIntegrity.
Device integrity issues: GET_INTEGRITY guides the user on how to get back to the MEETS_DEVICE_INTEGRITY state in deviceIntegrity.
Remediable error codes: GET_INTEGRITY resolves remediable API errors, such as prompting the user to fix network connectivity or update Google Play Services.
We also offer specialized dialogs including GET_STRONG_INTEGRITY (which works like GET_INTEGRITY while also getting the user back to the MEETS_STRONG_INTEGRITY state with no known malware issues in the playProtectVerdict), GET_LICENSED (which gets the user back to a Play licensed and Play recognized state), and CLOSE_UNKNOWN_ACCESS_RISK and CLOSE_ALL_ACCESS_RISK (which prompt the user to close potentially risky apps).
In addition to Play Integrity API, Google offers several other features to consider as part of your overall anti-abuse strategy. Both Play Integrity API and Play’s automatic protection offer user experience and developer benefits for safeguarding app distribution. We encourage existing apps to migrate to these modern integrity solutions instead of using the legacy Play licensing library.
Automatic protection: Prevent unauthorized access with Google Play’s automatic protection and ensure users continue getting your official app updates. Turn it on and Google Play will automatically add an installer check to your app’s code, with no developer integration work required. If your protected app is redistributed or shared through another channel, then the user will be prompted to get your app from Google Play. Eligible Play developers also have access to Play’s advanced anti-tamper protection, which uses obfuscation and runtime checks to make it harder and costlier for attackers to modify and redistribute protected apps.
With a strong foundation in hardware-backed security and new automated remediation dialogs simplifying integration, the Play Integrity API is an essential tool for protecting your growth.
Get started with the Play Integrity API documentation.
