Beta Channel Update for ChromeOS / ChromeOS Flex

The Beta channel is being updated to OS version: 15329.13.0, Browser version: 111.0.5563.14 for most ChromeOS devices.

If you find new issues, please let us know one of the following waysInterested in switching channels? Find out how.

Daniel Gagnon,
Google ChromeOS

Google Fiber continues to grow – Next Up: Westminster, Colorado, and Chandler, Arizona!

In 2022, Google Fiber kicked off expansion in five new states, and started the ball rolling in Mesa, Arizona, Omaha, Nebraska, and Lakewood, Colorado.  Those announcements were just the beginning. Today, we’re announcing the cities that are next up — Westminster, Colorado, and Chandler, Arizona!


Westminster, CO



Google Fiber has entered into an agreement with the City of Westminster, to provide fast, reliable internet to residents and businesses in the City. Right now, we’re working on engineering and planning for the new network. We expect to begin construction later this year and serve our first customers in early 2024. If you are interested in keeping up with our progress in Westminster, you can sign up for more information about availability and construction. 


Chandler, AZ


Thumbnail


Last night, the Chandler City Council approved a license agreement allowing Google Fiber to build a fiber-to-the-home network to serve residents and businesses with high speed, high bandwidth internet. Construction in Chandler will start later this year with service beginning in early 2024. If you are interested in getting updates on our progress and availability, sign up for more information here


Stay tuned - as we head into spring the forecast calls for more internet.


Posted by Sasha Petrovic, General Manager, Southwest Region, and Ashley Church, General Manager, West Region


Use Mobile Ads SDK Volume APIs Correctly to Maximize Video Ad Revenue

The volume control APIs provided by the Google Mobile Ads SDK are intended to mirror your app’s own custom volume controls. Utilizing these APIs ensures that the user receives video ads with the expected audio volume.

We’ll talk about some best practices implementing the volume control APIs in your iOS, Android or Unity project.

Why are we mentioning this?

Publishers can lose revenue when using these APIs to lower or mute the volume of the Google Mobile Ads SDK. Two issues we have commonly seen:

  1. Apps are using their own custom volume controls not sending the app’s accurate volume to the Google Mobile Ads SDK, but always sending zero
  2. App are just muting the SDK

Some apps have close to a 100% mute rate which doesn’t sound correct (pun intended). Setting application volume to zero or muting the application reduces video ad eligibility, which as a result may reduce your app’s ad revenue.

Volume control APIs

The Google Mobile Ads SDK offers two volume control APIs: setting the volume and toggling mute. These APIs are applicable to App Open, Banner, Interstitial, Rewarded and Rewarded Interstitial ad formats. For Native ads, use GADVideoOptions.

Setting application volume on each platform

iOS GADMobileAds.sharedInstance().applicationVolume = 1.0
Android MobileAds.setAppVolume(1.0f)
Unity MobileAds.SetApplicationVolume(1.0f)

Use applicationVolume to set your custom volume relative to the device volume. The range can be from 0.0 (silent) to 1.0 (current device volume). For example, if the device volume level was at half level and the user set your app’s custom volume to max level, set the applicationVolume to 1.0 and the user will receive an ad with the volume at half level.

Setting application mute on each platform

iOS GADMobileAds.sharedInstance().applicationMuted = true
Android MobileAds.setAppMuted(true)
Unity MobileAds.SetApplicationMuted(true)

Use applicationMuted if your custom volume controls include a mute button. Only toggle applicationMuted if the user selects your custom mute button. For example, if the user adjusts your custom volume to 0 you do not need to call applicationMuted; just call applicationVolume = 0.0.

Setting mute for native ads on each platform

iOS
let videoOptions = GADVideoOptions()
videoOptions.startMuted = true
adLoader = GADAdLoader(
adUnitID: "AD_UNIT_ID",
rootViewController: self,
adTypes: [ ... ad type constants ... ],
options: [videoOptions])
Android
val videoOptions = VideoOptions.Builder()
.setStartMuted(false)
.build()
val adOptions = NativeAdOptions.Builder()
.setVideoOptions(videoOptions)
.build()
val adLoader = AdLoader.Builder(this, "AD_UNIT_ID")
.forNativeAd( ... )
.withNativeAdOptions(adOptions)
.build()
Unity N/A - Native video ads are not supported in Unity.

Use startMuted if your custom volume controls include a mute button. Only toggle startMuted if the user selects your custom mute button.

Best Practices

To use our APIs as intended:

  1. applicationVolume should be called only when your custom volume control settings are set to reflect the new volume
  2. applicationMuted or startMuted should only be toggled to true if the user has muted your custom volume

As a rule of thumb, if your app does not have custom volume controls then you should not use these APIs.

What should you do?

To verify that your mobile applications are using these APIs correctly, we recommend that you enable test ads and force load a video test ad in your application. If your app has custom volume controls, the ad’s volume should be at the same level as the custom volume. Otherwise, the ad’s volume should match the device volume.

If you have any questions or need additional help, please contact us via the forum.

Amplification at the Quantum limit

The Google Quantum AI team is building quantum computers with superconducting microwave circuits, but much like a classical computer the superconducting processor at the heart of these computers is only part of the story. An entire technology stack of peripheral hardware is required to make the quantum computer work properly. In many cases these parts must be custom designed, requiring extensive research and development to reach the highest levels of performance.

In this post, we highlight one aspect of this supplemental hardware: our superconducting microwave amplifiers. In “Readout of a Quantum Processor with High Dynamic Range Josephson Parametric Amplifiers”, published in Applied Physics Letters, we describe how we increased the maximum output power of our superconducting microwave amplifiers by a factor of over 100x. We discuss how this work can pave the way for the operation of larger quantum processor chips with improved performance.


Why microwave amplifiers?

One of the challenges of operating a superconducting quantum processor is measuring the state of a qubit without disturbing its operation. Fundamentally, this comes down to a microwave engineering problem, where we need to be able to measure the energy inside the qubit resonator without exposing it to noisy or lossy wiring. This can be accomplished by adding an additional microwave resonator to the system that is coupled to the qubit, but far from the qubit’s resonance frequency. The resonator acts as a filter that isolates the qubit from the control lines but also picks up a state-dependent frequency shift from the qubit. Just like in the binary phase shift keying (BPSK) encoding technique, the digital state of the qubit (0 or 1) is translated into a phase for a probe tone (microwave signal) reflecting off of this auxiliary resonator. Measuring the phase of this probe tone allows us to infer the state of the qubit without directly interfacing with the qubit itself.

While this sounds simple, the qubit actually imposes a severe cap on how much power can be used for this probe tone. In normal operation, a qubit should be in the 0 state or the 1 state or some superposition of the two. A measurement pulse should collapse the qubit into one of these two states, but using too much power can push it into a higher excited state and corrupt the computation. A safe measurement power is typically around -125 dBm, which amounts to only a handful of microwave photons interacting with the processor during the measurement. Typically, small signals are measured using microwave amplifiers, which increase the signal level, but also add their own noise. How much noise is acceptable? If the measurement process takes too long, the qubit state can change due to energy loss in the circuit. This means that these very small signals must be measured in just a few hundred nanoseconds with very high (>99%) fidelity. We therefore cannot afford to average the signal over a longer time to reduce the noise. Unfortunately, even the best semiconductor low-noise amplifiers are still almost a factor of 10 too noisy.

The solution is to design our own custom amplifiers based on the same circuit elements as the qubits themselves. These amplifiers typically consist of Josephson junctions to provide a tunable inductance wired into a superconducting resonant circuit. By constructing a resonant circuit out of these elements, you can create a parametric amplifier where amplification is achieved by modulating the tunable inductance at twice the frequency you want to amplify. Additionally, because all of the wiring is made of lossless superconductors, these devices operate near the quantum limit of added noise, where the only noise in the signal is coming from amplification of the zero point quantum voltage fluctuations.

The one downside to these devices is that the Josephson junctions constrain the power of the signals we can measure. If the signal is too large, the drive current can approach the junction critical current and degrade the amplifier performance. Even if this limit was sufficient to measure a single qubit, our goal was to increase efficiency by measuring up to six qubits at a time using the same amplifier. Some groups get around this limit by making traveling wave amplifiers, where the signals are distributed across thousands of junctions. This increases the saturation power, but the amplifiers get very complicated to produce and take up a lot of space on the chip. Our goal was to create an amplifier that could handle as much power as a traveling wave amplifier but with the same simple and compact design we were used to.


Results

The critical current of each Josephson junction limits our amplifier’s power handling. However, increasing this critical current also changes the inductance and, thus, the operating frequency of the amplifier. To avoid these constraints, we replaced a standard 2-junction DC SQUID with a nonlinear tunable inductor made up of two RF-SQUID arrays in parallel, which we call a snake inductor. Each RF-SQUID consists of a Josephson junction and geometric inductances L1 and L2, and each array contains 20 RF-SQUIDs. In this case, each junction of a standard DC SQUID is replaced by one of these RF-SQUID arrays. While the critical current of each RF-SQUID is much higher, we chain them together to keep the inductance and operating frequency the same. While this is a relatively modest increase in device complexity, it enables us to increase the power handling of each amplifier by roughly a factor of 100x. It is also fully compatible with existing designs that use impedance matching circuits to provide large measurement bandwidth.

Circuit diagram of our superconducting microwave amplifier. A split bias coil allows both DC and RF modulation of the snake inductor, while a shunt capacitor sets the frequency range. The flow of current is illustrated in the animation where an applied current (blue) on the bias line causes a circulating current (red) in the snake. A tapered impedance transformer lowers the loaded Q of the device. Since the Q is defined as frequency divided by bandwidth, lowering the Q with a constant frequency increases the bandwidth of the amplifier. Example circuit parameters used for a real device are Cs=6.0 pF, L1=2.6 pH, L2=8.0 pH, Lb=30 pH, M=50 pH, Z0 = 50 Ohms, and Zfinal = 18 ohms. The device operation is illustrated with a small signal (magenta) reflecting off the input of the amplifier. When the large pump tone (blue) is applied to the bias port, it generates amplified versions of the signal (gold) and a secondary tone known as an idler (also gold).
Microscope image of the nonlinear resonator showing the resonant circuit that consists of a large parallel plate capacitor, nonlinear snake inductor, and a current bias transformer to tune the inductance.

We measure this performance improvement by measuring the saturation power of the amplifier, or the point at which the gain is compressed by 1 dB. We also measure this power value vs. frequency to see how it scales with amplifier gain and distance from the center of the amplifier bandwidth. Since the amplifier gain is symmetric about its center frequency we measure this in terms of absolute detuning, which is just the absolute value of the difference between the center frequency of the amplifier and the probe tone frequency.

Input and output saturation power (1-dB gain compression point), calibrated using a superconducting quantum processor vs. absolute detuning from the amplifier center frequency.

Conclusion and future directions

The new microwave amplifiers represent a big step forward for our qubit measurement system. They will allow us to measure more qubits using a single device, and enable techniques that require higher power for each measurement tone. However, there are still quite a few areas we would like to explore. For example, we are currently investigating the application of snake inductors in amplifiers with advanced impedance matching techniques, directional amplifiers, and non-reciprocal devices like microwave circulators.


Acknowledgements

We would like to thank the Quantum AI team for the infrastructure and support that enabled the creation and measurement of our microwave amplifier devices. Thanks to our cohort of talented Google Research Interns that contributed to the future work mentioned above: Andrea Iorio for developing algorithms that automatically tune amplifiers and provide a snapshot of the local parameter space, Ryan Kaufman for measuring a new class of amplifiers using multi-pole impedance matching networks, and Randy Kwende for designing and testing a range of parametric devices based on snake inductors. With their contributions, we are gaining a better understanding of our amplifiers and designing the next generation of parametrically-driven devices.

Source: Google AI Blog


Beta Channel Update for Desktop

 The Chrome team is excited to announce the promotion of Chrome 111 to the Beta channel for Windows, Mac and Linux. Chrome 111.0.5563.19 contains our usual under-the-hood performance and stability tweaks, but there are also some cool new features to explore - please head to the Chromium blog to learn more!



A full list of changes in this build is available in the log. Interested in switching release channels? Find out how here. If you find a new issues, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Prudhvikumar Bommana Google Chrome

Chrome Dev for Android Update

Hi everyone! We've just released Chrome Dev 112 (112.0.5582.0) for Android. It's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Krishna Govind
Google Chrome

Chrome Beta for Android Update

Hi everyone! We've just released Chrome Beta 111 (111.0.5563.15) for Android. It's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Harry Souders
Google Chrome

February 2023 update to Display & Video 360 API

Today we’re announcing the February 2023 update to Display & Video 360 API. This update includes the following features:

More detailed information about this update can be found in the Display & Video 360 API release notes.

Before using these new features, make sure to update your client library to the latest version. We have also added a new guide page on retrieving YouTube & Partners line items using the Display & Video 360 API.

If you have questions regarding the breaking changes, run into issues, or need help with these new features, please contact us using our support contact form.