Google talks possible 120Hz refresh rate on Pixel 3, High Brightness Mode, Pixel 4 haptics, and more
The latest episode of the Android Developers Backstage podcast was released recently. This time around it featured Michael Wright from the Android Framework Team, Chet Haase from the Android Developer Relations team, and Romain Guy from the Android Toolkit team. In this episode, the developers focused on a couple of interesting topics, including the possibility of a 120Hz display on the Google Pixel 3, high brightness mode, Pixel 4 haptics, and more. Here’s a rundown of all the key issues the tackled in episode 129:
Google Pixel 3 with High Refresh Rate Display?
With the launch of the Pixel 4, Google jumped onto the high refresh rate display bandwagon and packed in a 90Hz display on both the devices. But did you know that Google contemplated including a 120Hz refresh rate display on the Pixel 3? According to Haase from the Android Developer Relations team, the smaller Pixel 3 wasn’t supposed to get an OLED display for various reasons, which is why Google considered using a Sharp 120Hz display on the device. Haase said, “So it was like ‘well, if we don’t have OLED, what do we do?’ and so one of of the considerations was ‘well maybe we do a 120Hz LCD.'” Sadly, Haase didn’t reveal why the company finally chose a P-OLED panel over the 120Hz LCD.
What did Google do to make high refresh rate applicable to the whole ecosystem?
In the episode, the developers also shed some light on how Google managed to make high refresh rate applicable to the Android ecosystem as a whole. The company introduced a dynamic refresh rate switching feature in Android 10 to automatically switch between 90 and 60Hz for power saving. The company acknowledges problems in earlier builds (likely referring to the brightness fiasco) but says that they’re now in a much better place.
One of the team’s big issues with the Pixel 4 is that it uses 120Hz touch sampling. The company agreed to use 120Hz because switching between 120Hz and 180 Hz touch sampling was challenging and had a big power cost. The team suspects that this will change in the future as the company figures out how to get the power cost down and handle that much more input. 90Hz refresh rate and 120Hz touch sampling aren’t an ideal combination because the 120Hz touch sampling means that an input comes in every other frame.
To deal with this issue, Google used resampling which was introduced with Project Butter in Android 4.1 to interpolate/predict touch events. Google is also investigating a new technique called late-latching, in which they will resample events at the last possible moment right before rendering. This new technique is expected to improve the experience during scrolling lists.
During the podcast, the developers also revealed that Google considered adjusting the brightness based on applications in Android 10. The reasoning was that since most people turn up the brightness for photos and videos it would make sense for Android to do this automatically. As it turns out, that was a really bad idea because people hated this loss of control. Therefore, it wasn’t implemented.
However, having higher brightness is important for viewing HDR content, so Google uses High Brightness Mode (HBM) only for HDR content. On the Pixel series, HBM bumps up the brightness to ~600-700 nits depending on the panel. Wright added that you need about 700 nits to be sunlight-readable in all cases, but the Pixel does not use HBM in sunlight. The reason HBM is not in use outside of HDR video is primarily because of burn-in concerns rather than power.
Pixel 4 Haptics
Finally, the podcast shifts focus to the haptics on the Pixel 4 series. In case you own a Pixel 4, you might have noticed that the devices vibrate smoothly with audio from ringtones and alarms. In previous versions of the Pixel series, Google had to create a haptic config for each ringtone and alarm sound to achieve this effect, but this changed with the Pixel 4.
With the Pixel 4, Google introduced audio-coupled haptic feedback. Now there is a channel in the audio container that is actually a haptic signal because the haptic signal looks like a really low-frequency audio signal. However, this is only available with pre-included ringtones and alarms. The devices have no on-the-fly coupling for third-party ringtones and alarms. There’s no documentation for third-party developers to do this on their own audio yet since audio-coupled haptic feedback isn’t available on all devices.
You can listen to the entire episode on Google Podcasts by following this link.
Thanks to XDA contributor Dylan Raga for help in putting this recap together!