Long Term Support Channel Update for ChromeOS

A new LTS-138  version 138.0.7204.305 (Platform Version: 16295.90.0), is being rolled out for most ChromeOS devices. 


This version includes selected security fixes including:


483569511  High CVE-2026-2441 Use after free in CSS.

452209495  Medium CVE-2026-0904 Incorrect security UI in Digital Credentials.

481074858  High CVE-2026-2649 Integer overflow in V8.

469143679  Medium CVE-2026-0902 Inappropriate implementation in V8.


And also:

CVE-2025-37890, CVE-2025-38177, CVE-2025-38000, CVE-2025-38001, CVE-2025-38083, CVE-2025-38350, CVE-2025-38477, CVE-2025-38618, CVE-2025-38617, CVE-2025-38616,

Release notes for LTS-138 can be found here 

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

Andy Wu

Google ChromeOS


Cultivating a robust and efficient quantum-safe HTTPS

Today we're announcing a new program in Chrome to make HTTPS certificates secure against quantum computers. The Internet Engineering Task Force (IETF) recently created a working group, PKI, Logs, And Tree Signatures (“PLANTS”), aiming to address the performance and bandwidth challenges that the increased size of quantum-resistant cryptography introduces into TLS connections requiring Certificate Transparency (CT). We recently shared our call to action to secure quantum computing and have written about challenges introduced by quantum-resistant cryptography and some of the steps we’ve taken to address them in earlier blog posts.

To ensure the scalability and efficiency of the ecosystem, Chrome has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store. Instead, Chrome, in collaboration with other partners, is developing an evolution of HTTPS certificates based on Merkle Tree Certificates (MTCs), currently in development in the PLANTS working group. MTCs replace the heavy, serialized chain of signatures found in traditional PKI with compact Merkle Tree proofs. In this model, a Certification Authority (CA) signs a single "Tree Head" representing potentially millions of certificates, and the "certificate" sent to the browser is merely a lightweight proof of inclusion in that tree.

Why MTCs?

MTCs enable the adoption of robust post-quantum algorithms without incurring the massive bandwidth penalty of classical X.509 certificate chains. They also decouple the security strength of the corresponding cryptographic algorithm from the size of the data transmitted to the user. By shrinking the authentication data in a TLS handshake to the absolute minimum, MTCs aim to keep the post-quantum web as fast and seamless as today’s internet, maintaining high performance even as we adopt stronger security. Finally, with MTCs, transparency is a fundamental property of issuance: it is impossible to issue a certificate without including it in a public tree. This means the security properties of today’s CT ecosystem are included by default, and without adding extra overhead to the TLS handshake as CT does today.

Chrome’s MTC Propagation Plan

Chrome is already experimenting with MTCs with real internet traffic, and we intend to gradually build out our deployment such that MTCs provide a robust quantum-resistant HTTPS available for use throughout the internet.

Broadly speaking, our rollout spans three distinct phases.

  • Phase 1 (UNDERWAY): In collaboration with Cloudflare, we are conducting a feasibility study to evaluate the performance and security of TLS connections relying on MTCs. To ensure a seamless and secure experience for Chrome users who might encounter an MTC, every MTC-based connection is backed by a traditional, trusted X.509 certificate during this experiment. This "fail safe" allows us to measure real-world performance gains and verify the reliability of MTC issuance without risking the security or stability of the user's connection.
  • Phase 2 (Q1 2027): Once the core technology is validated, we intend to invite CT Log operators with at least one “usable” log in Chrome before February 1, 2026 to participate in the initial bootstrapping of public MTCs. These organizations have already demonstrated the operational excellence and high-availability infrastructure required to run global security services that underpin TLS connections in Chrome. Since MTC technology shares significant architectural similarities with CT, these operators are uniquely qualified to ensure MTCs are able to get off the ground quickly and successfully.
  • Phase 3 (Q3 2027): Early in Phase 2, we will finalize the requirements for onboarding additional CAs into the new Chrome Quantum-resistant Root Store (CQRS) and corresponding Root Program that only supports MTCs. This will establish a modern, purpose-built trust store specifically designed for the requirements of a post-quantum web. The Chrome Quantum-resistant Root Program will operate alongside our existing Chrome Root Program to ensure a risk-managed transition that maintains the highest levels of security for all users. This phase will also introduce the ability for sites to opt in to downgrade protections, ensuring that sites that only wish to use quantum-resistant certificates can do so.

This area is evolving rapidly. As these phases progress, we will continue our active participation in standards bodies such as the IETF and C2SP, ensuring that insights gathered from our efforts flow back towards standards, and that changes in standards are supported by Chrome and the CQRS.

Cultivating new practices and policy for a more secure and reliable web

We view the adoption of MTCs and a quantum-resistant root store as a critical opportunity to ensure the robustness of the foundation of today’s ecosystem. By designing for the specific demands of a modern, agile, internet, we can accelerate the adoption of post-quantum resilience for all web users.

We expect this modern foundation for TLS to evolve beyond current ecosystem norms and emphasize themes of security, simplicity, predictability, transparency and resilience. These properties might be expressed by:

  • Grounding our approach in first principles, prioritizing only elements essential for establishing a secure connection between a server and a client.
  • Utilizing ACME-only workflows to reduce complexity and ensure the cryptographic agility required to respond to future threats across the entire ecosystem.
  • Upgrading to a modern framework for communicating revocation status. This allows for the replacement of legacy CRLs and streamlined requirements to focus only on key compromise events.
  • Exploring “reproducible” Domain Control Validation to create a model where proofs of domain control are publicly and persistently available, empowering any party to independently verify the legitimacy of a validation (i.e., serve as a “DCV Monitor”).
  • Enhancing the CA inclusion model to prioritize proven operational excellence. By establishing a pathway where prospective MTC CA Owners can first demonstrate their reliability as Mirroring Cosigners and DCV Monitors, we ensure that acceptance is based on verified performance and a reliable track record.
  • Evolving the third-party oversight model to prioritize complete, continuous, and externally verifiable monitoring. This shift would focus on ensuring a high standard of transparency and consistency, providing immediate and reliable insights into performance that can replace the function of annual third-party audits.

To secure the future of the web, we are dedicating our operational resources to two vital parallel tracks. First, we remain fully committed to supporting our current CA partners in the Chrome Root Store, facilitating root rotations to ensure existing non-quantum-resistant hierarchies remain robust and conformant with the Chrome Root Program Policy. Simultaneously, we are focused on building a secure future by developing and launching the infrastructure required to support MTCs and their default use in Chrome. We also expect to support “traditional” X.509 certificates with quantum-resistant algorithms for use only in private PKIs (i.e., those not included in the Chrome Root Store) later this year.

As we execute and refine our work on MTCs, we look forward to sharing a concrete policy framework for a quantum-resistant root store with the community, and are excited to learn and define clear pathways for organizations to operate as Chrome-trusted MTC CAs.

Minimum Budget Requirement for Demand Gen Campaigns

Starting on April 1st, 2026, the Google Ads API will begin enforcing a minimum daily budget of 5 USD, or the equivalent in local currency, for all Demand Gen campaigns. This update ensures that campaigns have adequate budget to navigate the initial "cold start" phase, during which our models learn and optimize for performance.

This change is being implemented as an unversioned update across the Google Ads API, providing consistency across all buying doors.

Technical details and error handling

Depending on the version of the API you are using, you will encounter different behaviors when a budget below the 5 USD floor is specified for a Demand Gen campaign:

  • Google Ads API v21 and above: You will receive a BUDGET_BELOW_DAILY_MINIMUM error when creating or updating a campaign with an insufficient budget. You can also refer to the details.budget_per_day_minimum_error_details field for further details about the minimum budget, such as the actual minimum threshold.
  • Google Ads API v20: The API will return a generic UNKNOWN error code. To identify this specific validation failure, you must check the details.unpublished_error_code field, which will contain the string CampaignBudgetError.BUDGET_BELOW_DAILY_MINIMUM.

The validation will trigger whenever a campaign's budget, start time, or end time is modified in a way that results in a daily budget below the floor. This applies to both daily budgets and flighted (custom) budgets.

Impact on existing campaigns

Existing Demand Gen campaigns that currently operate with a budget below the 5 USD threshold will continue to serve without interruption. However, any future modifications to these campaigns' budgets or durations will be subject to the new validation rules. To make a change to these campaigns, the budget must be increased to at least the minimum required floor.

Next steps

We recommend that developers update their reporting and management systems to handle these new error codes.

If you have any questions regarding this change, get Google Ads API support.

On-Device Function Calling in Google AI Edge Gallery

Google has introduced FunctionGemma, a specialized 270M parameter model designed to bring efficient, action-oriented AI experiences directly to mobile devices through on-device function calling. By leveraging Google AI Edge and LiteRT-LM, the model enables complex tasks—such as managing calendars, controlling device hardware, or executing specific game logic in the "Tiny Garden" demo—to be performed entirely offline with high speed and low latency. Available for testing in the Google AI Edge Gallery app on both Android and iOS, FunctionGemma allows developers to move beyond simple text generation toward building responsive, "agentic" applications that interact seamlessly with the physical and digital world without relying on cloud processing.

The Second Beta of Android 17

Posted by Matthew McCullough, VP Product Management, Android Developer


Today we're releasing the second beta of Android 17, continuing our work to build a platform that prioritizes privacy, security, and refined performance. This update delivers a range of new capabilities, including the EyeDropper API and a privacy-preserving Contacts Picker. We're also adding advanced ranging, cross-device handoff APIs, and more.

This release continues the shift in our release cadence, following this annual major SDK release in Q2 with a minor SDK update.

User Experience & System UI

Bubbles

Bubbles is a windowing mode feature that offers a new floating UI experience separate from the messaging bubbles API. Users can create an app bubble on their phone, foldable, or tablet by long-pressing an app icon on the launcher. On large screens, there is a bubble bar as part of the taskbar where users can organize, move between, and move bubbles to and from anchored points on the screen.


You should follow the guidelines for supporting multi-window mode to ensure your apps work correctly as bubbles.


EyeDropper API


A new system-level EyeDropper API allows your app to request a color from any pixel on the display without requiring sensitive screen capture permissions.


val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) {
  result -> if (result.resultCode == Activity.RESULT_OK) {
    val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK)
    // Use the picked color in your app
  }
}

fun launchColorPicker() {
  val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER)
  eyeDropperLauncher.launch(intent)
}

Contacts Picker

A new system-level contacts picker via ACTION_PICK_CONTACTS grants temporary, session-based read access to only the specific data fields requested by the user, reducing the need for the broad READ_CONTACTS permissions. It also allows for selections from the device’s personal or work profiles.






val contactPicker = rememberLauncherForActivityResult(StartActivityForResult()) {
    if (it.resultCode == RESULT_OK) {
        val uri = it.data?.data ?: return@rememberLauncherForActivityResult
        // Handle result logic
        processContactPickerResults(uri)
    }
}

val dataFields = arrayListOf(Email.CONTENT_ITEM_TYPE, Phone.CONTENT_ITEM_TYPE)
val intent = Intent(ACTION_PICK_CONTACTS).apply {
    putStringArrayListExtra(EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS, dataFields)
    putExtra(EXTRA_ALLOW_MULTIPLE, true)
    putExtra(EXTRA_PICK_CONTACTS_SELECTION_LIMIT, 5)
}

contactPicker.launch(intent)


Easier pointer capture compatibility with touchpads

Previously, touchpads reported events in a very different way from mice when an app had captured the pointer, reporting the locations of fingers on the pad rather than the relative movements that would be reported by a mouse. This made it quite difficult to support touchpads properly in first-person games. Now, by default the system will recognize pointer movement and scrolling gestures when the touchpad is captured, and report them just like mouse events. You can still request the old, detailed finger location data by explicitly requesting capture in the new “absolute” mode.


// To request the new default relative mode (mouse-like events)
// This is the same as requesting with View.POINTER_CAPTURE_MODE_RELATIVE
view.requestPointerCapture()

// To request the legacy absolute mode (raw touch coordinates)
view.requestPointerCapture(View.POINTER_CAPTURE_MODE_ABSOLUTE)


Interactive Chooser resting bounds

By calling getInitialRestingBounds on Android's ChooserSession, your app can identify the target position the Chooser occupies after animations and data loading are complete, enabling better UI adjustments.

Connectivity & Cross-Device

Cross-device app handoff

A new Handoff API allows you to specify application state to be resumed on another device, such as an Android tablet. When opted in, the system synchronizes state via CompanionDeviceManager and displays a handoff suggestion in the launcher of the user's nearby devices. This feature is designed to offer seamless task continuity, enabling users to pick up exactly where they left off in their workflow across their Android ecosystem. Critically, Handoff supports both native app-to-app transitions and app-to-web fallback, providing maximum flexibility and ensuring a complete experience even if the native app is not installed on the receiving device.


Advanced ranging APIs

We are adding support for 2 new ranging technologies - 

  1. UWB DL-TDOA which enables apps to use UWB for indoor navigation. This API surface is FIRA (Fine Ranging Consortium) 4.0 DL-TDOA spec compliant and enables privacy preserving indoor navigation  (avoiding tracking of the device by the anchor).

  2. Proximity Detection which enables apps to use the new ranging specification being adopted by WFA (WiFi Alliance). This technology provides improved reliability and accuracy compared to existing Wifi Aware based ranging specification.

Data plan enhancements

To optimize media quality, your app can now retrieve carrier-allocated maximum data rates for streaming applications using getStreamingAppMaxDownlinkKbps and
getStreamingAppMaxUplinkKbps.

Core Functionality, Privacy & Performance

Local Network Access

Android 17 introduces the ACCESS_LOCAL_NETWORK runtime permission to protect users from unauthorized local network access. Because this falls under the existing NEARBY_DEVICES permission group, users who have already granted other NEARBY_DEVICES permissions will not be prompted again. By declaring and requesting this permission, your app can discover and connect to devices on the local area network (LAN), such as smart home devices or casting receivers. This prevents malicious apps from exploiting unrestricted local network access for covert user tracking and fingerprinting. Apps targeting Android 17 or higher will now have two paths to maintain communication with LAN devices: adopt system-mediated, privacy-preserving device pickers to skip the permission prompt, or explicitly request this new permission at runtime to maintain local network communication.

Time zone offset change broadcast

Android now provides a reliable broadcast intent, ACTION_TIMEZONE_OFFSET_CHANGED, triggered when the system's time zone offset changes, such as during Daylight Saving Time transitions. This complements the existing broadcast intents ACTION_TIME_CHANGED and ACTION_TIMEZONE_CHANGED, which are triggered when the Unix timestamp changes and when the time zone ID changes, respectively.


NPU Management and Prioritization

Apps targeting Android 17 that need to directly access the NPU must declare FEATURE_NEURAL_PROCESSING_UNIT in their manifest to avoid being blocked from accessing the NPU. This includes apps that use the LiteRT NPU delegate, vendor-specific SDKs, as well as the deprecated NNAPI.


ICU 78 and Unicode 17 support

Core internationalization libraries have been updated to ICU 78, expanding support for new scripts, characters, and emoji blocks, and enabling direct formatting of time objects.

SMS OTP protection

Android is expanding its SMS OTP protection by automatically delaying access to SMS messages with OTP. Previously, the protection was primarily focused on the SMS Retriever format wherein the delivery of messages containing an SMS retriever hash is delayed for most apps for three hours. However, for certain apps like the default SMS app, etc and the app that corresponds to the hash are exempt from this delay. This update extends the protection to all SMS messages with OTP. For most apps, SMS messages containing an OTP will only be accessible after a delay of three hours to help prevent OTP hijacking. The SMS_RECEIVED_ACTION broadcast will be withheld and sms provider database queries will be filtered. The SMS message will be available to these apps after the delay.


Delayed access to WebOTP format SMS messages

If the app has the permission to read SMS messages but is not the intended recipient of the OTP (as determined by domain verification), the WebOTP format SMS message will only be accessible after three hours have elapsed. This change is designed to improve user security by ensuring that only apps associated with the domain mentioned in the message can programmatically read the verification code. This change applies to all apps regardless of their target API level.

Delayed access to standard SMS messages with OTP

For SMS messages containing an OTP that do not use the WebOTP or SMS Retriever formats, the OTP SMS will only be accessible after three hours for most apps. This change only applies to apps that target Android 17 (API level 37) or higher.

Certain apps such as the default SMS, assistant app, along with connected device companion apps, etc will be exempt from this delay.

All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.


The Android 17 schedule

We're going to be moving quickly from this Beta to our Platform Stability milestone, targeted for March. At this milestone, we'll deliver final SDK/NDK APIs. From that time forward, your app can target SDK 37 and publish to Google Play to help you complete your testing and collect user feedback in the several months before the general availability of Android 17.


A year of releases

We plan for Android 17 to continue to get updates in a series of quarterly releases. The upcoming release in Q2 is the only one where we introduce planned app breaking behavior changes. We plan to have a minor SDK release in Q4 with additional APIs and features.





Get started with Android 17

You can enroll any supported Pixel device to get this and future Android Beta updates over-the-air. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio.

If you are currently in the Android Beta program, you will be offered an over-the-air update to Beta 2.

If you have Android 26Q1 Beta and would like to take the final stable release of 26Q1 and exit Beta, you need to ignore the over-the-air update to 26Q2 Beta 2 and wait for the release of 26Q1.

We're looking for your feedback so please report issues and submit feature requests on the feedback page. The earlier we get your feedback, the more we can include in our work on the final release.

For the best development experience with Android 17, we recommend that you use the latest preview of Android Studio (Panda). Once you’re set up, here are some of the things you should do:

  • Compile against the new SDK, test in CI environments, and report any issues in our tracker on the feedback page.

  • Test your current app for compatibility, learn whether your app is affected by changes in Android 17, and install your app onto a device or emulator running Android 17 and extensively test it.

We’ll update the preview/beta system images and SDK regularly throughout the Android 17 release cycle. Once you’ve installed a beta build, you’ll automatically get future updates

over-the-air for all later previews and Betas.

For complete information, visit the Android 17 developer site.

Join the conversation

As we move toward Platform Stability and the general availability of Android 17 later this year, your feedback remains our most valuable asset. Whether you’re an early adopter on   the Canary channel or an app developer testing on Beta 2, consider joining our communities and filing feedback. We’re listening.

Introducing Nano Banana 2 in the Gemini app


Starting today, we’re rolling out Nano Banana 2 (Gemini 3.1 Flash Image), our best image model yet, to Workspace customers in the Gemini app.

Nano Banana 2, which replaces our previous Nano Banana model, brings the high-speed intelligence of Gemini Flash to visual generation, making once-exclusive Pro features accessible to a wider audience, including:

  • Advanced world knowledge: Nano Banana 2 pulls from the Gemini model’s real-world knowledge base and is powered by real-time information and images from web search to more accurately render specific subjects. This deep understanding also empowers you to create infographics, turn notes into diagrams, and generate data visualizations.
  • Production-ready specs: Make attention-grabbing assets with full control over aspect ratios and resolutions—ranging from 1K for free and 2K for paid users. Your visuals will stay sharp and perfectly sized, whether you are generating a vertical social media Story or a wide-screen presentation backdrop.
  • Precision text rendering and translation: Generate accurate, legible text for infographics or marketing mockups. Users can even translate and localize text within an image to share your ideas globally.
Nano Banana 2 also dramatically closes the gap between speed and beauty, delivering high-fidelity, photorealistic imagery. Here’s what our newest model offers and has improved on from the original Nano Banana:

  • Subject consistency: Maintain character resemblance of up to five characters and the fidelity of up to ten objects in a single workflow in the Gemini app, allowing you to storyboard and build narratives without altering the appearance of your inputs.
  • Precise instruction following: With enhanced instruction following, the model adheres more strictly to your complex requests, capturing the specific nuances of your idea so the image you get is the image you asked for.
  • Visual fidelity upgrade: Nano Banana 2 delivers vibrant lighting, richer textures, and sharper details, maintaining high-quality aesthetics at the speed expected from Flash.

Getting started

  • Admins: There are no admin controls for this feature.
  • End users: Visit the Help Center for more information on generating images in Gemini.

Rollout pace

Availability

Nano Banana 2 will replace Nano Banana Pro across the Fast, Thinking and Pro models for Google Workspace customers, Workspace Individual subscribers, and users with personal Google accounts who are 18 years or older and signed in to the Gemini app. Workspace users who have had access to Nano Banana Pro will keep access to Nano Banana Pro for specialized tasks by regenerating images via the three-dot menu.

Resources

Stable Channel Update for ChromeOS / ChromeOS Flex

M-145, ChromeOS version 16552.47.0 (Browser version 145.0.7632.154) has rolled out to ChromeOS devices on the Stable channel. 

If you find new issues, please let us know one of the following ways:


  1. File a bug

  2. Visit our ChromeOS communities

    1. General: Chromebook Help Community

    2. Beta Specific: ChromeOS Beta Help Community

  3. Report an issue or send feedback on Chrome

  4. Interested in switching channels? Find out how.



Security Fixes and Rewards

ChromeOS Vulnerability Rewards Program Reported Bug Fixes:

N/A

Other 3rd Party Security Fixes Included:


High Fixes CVE-2025-38349 kernel Use-After-Free (UAF) fix

High Fixes CVE-2025-0932 potential UAF in the ARM shader compiler reachable through WebGPU

High Fixes CVE-2025-21704 buffer size check in the USB CDC-ACM driver


Android Security fixes can be found here


Chrome Browser Security Fixes:


[$TBD] [478560268] High CVE-2026-2314 blink_avif_decoder_fuzzer: Heap-buffer-overflow in InterpolateRow_Any_AVX2  on  2026-01-25 

[$1000.0] [470928605] Low CVE-2026-2322 On Ubuntu (or other Linux-based systems) an attacker can steal files uploaded to other sites with little user interaction.  on  2025-12-22 

[$500.0] [467442136] Low CVE-2026-2323 when the filename contains a very long with special character can break/remove the extension of file in download buble Reported by [[goes here]] on  2025-12-09 

[$8000.0] [467297219] High CVE-2026-2313 Use-After-Poison in RouteMap::UpdateActiveRoutes  on  2025-12-09 

[$2000.0] [464173573] Medium CVE-2026-2317 KeyframeEffect constructor leaks UA shadow root. Reported by [Brendan Draper] on  2025-11-27 

[$TBD] [461877477] Medium CVE-2026-2321 heap-use-after-free : base::ScopedObservationTraits<ui::WaylandWpColorManager, ui::WaylandWpColorManager::Observer>::RemoveObserver  on  2025-11-18 

[$TBD] [435684924] Medium CVE-2026-2320 Security: Compromised renderer can read files through file picker dialog with kSave mode + prefilled filename Reported by [Alesandro Ortiz https://AlesandroOrtiz.com] on  2025-08-01 

[$5000.0] [422531206] Medium CVE-2026-2316 Intersection Observer v2 API fails to correctly determine target's visibility for dynamically changed z-indexes, enabling clickjacking against Google One Tap Reported by [Luan Herrera (@lbherrera_)] on  2025-06-04 

[$1000.0] [363930141] Medium CVE-2026-2318 User can unknowingly Execute External File Hidden behind PiP during Interaction Reported by [Shaheen Fazim] on  2024-09-02 

[$1000.0] [40071155] Medium CVE-2026-2319 UAF in v8_inspector DomainDispatcherImpl  on  2023-09-01 

[$TBD] [483569511] High CVE-2026-2441 Heap-use-after-free in blink::FontFeatureValuesMapIterationSource::FetchNextItem Reported by [Shaheen Fazim] on  2026-02-11 

[$11000.0] [481074858] High CVE-2026-2649 V8: Integer Truncation in Turboshaft PhiOp input_count via WASM br_table Reported by [JunYoung Park(@candymate) of KAIST Hacking Lab] on  2026-02-02 

[$11000.0] [477033835] High CVE-2026-2648 PDFium  heap-buffer-overflow at opj_j2k_read_sod Reported by [soiax] on  2026-01-19 

[$TBD] [476461867] Medium CVE-2026-2650 media_pipeline_integration_fuzzer: Heap-buffer-overflow in media::AudioBuffer::AudioBuffer  on  2026-01-17 


Andy Wu

Google ChromeOS