We are excited to bring Express checkout with Google Pay for Android native apps enabling developers...

When creating a notebook in Powerschool Schoology, Gemini LTI users can now add content directly from their course as sources. This integration allows educators and students to seamlessly bridge their course materials with AI-powered research and analysis, and generate Studio artifacts like Audio and Video Overviews, infographics, slide decks, and more based on their Schoology resources. By automating the import of Schoology course materials, users can quickly ground their notebooks in specific curriculum content without the need for manual file uploads.

Getting started

Availability

Resources

Posted by Jingyu Shi, Staff Developer Relations Engineer

We’re making it easier to keep your sources and insights current in NotebookLM by enabling automatic syncing with Google Drive. Previously, if you uploaded a file in Google Docs, Sheets, or Slides, you’d have to manually update it in NotebookLM to see the changes. With this update, as the content in your Drive files evolves, the information within the notebook updates automatically to match. This update ensures that you're always working with the most accurate and up-to-date information without the manual effort of re-syncing files.

Getting started

Rollout pace

Availability

Resources

Today, we’re announcing improvements to our Out-of-Domain file-level warnings. First launched in April 2025, these badges alert users to documents and users outside of their Workspace organization, helping to prevent accidental data exfiltration and potential phishing attacks that spoof internal content. We’ve expanded support across devices and sharing types in the following ways:

Making decisions in a fast-paced environment often leads to long, messy threads and lost consensus. Polly helps teams solve this by enabling the creation of interactive polls within existing Chat conversations. By keeping the feedback loop inside the "flow of work," Polly helps eliminate the friction of switching between apps, leading to faster responses and clearer team alignment.

Getting started

Rollout pace

Availability

Resources

We’re updating icons across Google Workspace to introduce a modern visual design that gives every app a more distinct identity. Over the next several weeks, users will see new icons for Gmail, Calendar, Chat, Meet, Drive, Docs, Slides, Sheets, Vids, Keep, Forms, Voice, Sites, and Tasks.

Getting started

Rollout pace

Impact

Resources

We designed the Google Health App to bring your data into one secure place, no matter what device you use.

by Jens Nyman, TestParameterInjector Team

In March 2021, we announced the open source release of TestParameterInjector: a simple but powerful parameterized test runner for JUnit4. In September 2022, we followed up with JUnit5 support, bringing our framework to developers who had moved on to the Jupiter API.

We're excited to announce our biggest update yet for our Kotlin users: KotlinTestParameters.

The de facto standard for parameterized testing

When we first introduced TestParameterInjector, we shared a graph showing its rapid adoption within Google. Over the past few years, that trajectory has continued to a point where TestParameterInjector is the de facto parameterized test framework.

Usage of all other alternative frameworks continues to steadily decline, while TestParameterInjector's adoption keeps growing rapidly. It has fundamentally lowered the barrier to writing data-driven unit tests, empowering Googlers and open source developers alike to maximize test coverage with minimal boilerplate. We believe its ubiquity internally is a strong testament to its reliability and utility for the broader developer communities.

The Kotlin challenge

As Kotlin's popularity has surged, developers have naturally been writing more of their TestParameterInjector tests in Kotlin. However, specifying explicit test values in Kotlin historically meant falling back to Java-centric paradigms.

If you wanted to provide specific values to a test, you typically had three options, none of which felt truly idiomatic in Kotlin:

1. @TestParameter({"123", "456"}): This relies on string arrays, limiting you to a subset of types that the string parsing supports.
2. @TestParameters: This allows for more complex sets of data, but relies on YAML strings (e.g.,"{age: 17, expectIsAdult: false}"). These strings however are not type-safe, and are completely ignored by IDE refactoring tools.
3. Provider classes: For complex types that couldn't be easily represented in strings, you have to write Provider classes, adding a bit of boilerplate code and indirection.

Enter KotlinTestParameters

To bring a seamless experience to Kotlin, we are introducing a significant new Kotlin-only feature: KotlinTestParameters.

By leveraging Kotlin's default function arguments, you can now define parameterized tests in a fully type-safe, concise, and refactor-friendly way using the testValues() function (and friends).

Here is what it looks like in practice:

import com.google.testing.junit.testparameterinjector.TestParameterInjector
import com.google.testing.junit.testparameterinjector.TestParameter
import com.google.testing.junit.testparameterinjector.KotlinTestParameters.testValues
import com.google.testing.junit.testparameterinjector.KotlinTestParameters.namedTestValues
import org.junit.Test
import org.junit.runner.RunWith

@RunWith(TestParameterInjector::class)
class MyTest {

  // Testing simple types directly
  @Test
  fun simpleTest(@TestParameter limit: Int = testValues(20, 100)) {
    // This test method is run twice: once for limit=20 and once for limit=100
  }

  // Testing complex types without YAML strings or Provider classes!
  data class TestCase(val age: Int, val expectIsAdult: Boolean)

  @Test
  fun complexTest(
    @TestParameter testCase: TestCase = namedTestValues(
      "teenager" to TestCase(age = 17, expectIsAdult = false),
      "young adult" to TestCase(age = 22, expectIsAdult = true)
    )
  ) {
    // This test method is run twice with fully typed data class instances
  }
}

Why we recommend making the switch

Because testValues() seamlessly integrates with Kotlin's language features, any type is supported. This completely eliminates the need for stringly-typed YAML maps or verbose Provider classes.

We firmly believe that KotlinTestParameters is a massive leap forward in readability and maintainability. Moving forward, this should be the default way of specifying test values for all new Kotlin tests, replacing the older @TestParameters, @TestParameter({"..."}), and Provider class patterns.

Try it out!

You can read more and start using KotlinTestParameters today over on our GitHub repository.

Let us know what you think on GitHub if you have any questions, comments, or feature requests!

A new LTS-144  version 144.0.7559.252 (Platform Version: 16503.84.0), is being rolled out for most ChromeOS devices. 

This version includes selected security fixes including:

495931147 High CVE-2026-5289: Use after free in Navigation.

497846428 High CVE-2026-6309: Use after free in Viz.

487117772 High CVE-2026-4449: Use after free in Blink.

488188166 High CVE-2026-4674: Out of bounds read in CSS.

497412658 High CVE-2026-6308: Out of bounds read in Media.

482828615 High CVE-2026-3916: Out of bounds read in Web Speech.

484751092 High CVE-2026-4442: Heap buffer overflow in CSS.

489619753 High CVE-2026-4458: Use after free in Extensions.

487768779 High CVE-2026-4451 Insufficient validation of untrusted input in Navigation.

492213293 Medium CVE-2026-5292: Out of bounds read in WebCodecs.

491655161 Medium CVE-2026-5282: Out of bounds read in WebCodecs.

Release notes for LTS-144 can be found here 

Want to know more about Long-term Support? Click here

Andy Wu

Google Chrome OS