The Pixel Watch 2 launches with Wear OS 4 based on Android 13, which brings support for the new Watch Face Format, enhanced Tile support, cloud backup and restore, and seamless data transfer to a new phone!

Watch Face Format is a declarative XML format that lets you design the appearance and behavior of watch faces. No executable code is involved in making a watch face. Wear OS handles the logic of rendering the watch face, so you don't have to worry about code optimizations or battery performance.

Version 1.2 of the Jetpack Tiles library adds support for platform data bindings and animations.

I'm most excited for cloud backup and store and seamless data transfer, though.

Cloud backup and restore: "On devices that support cloud backup—including Pixel Watch 2 and Pixel Watch—users can transfer data from one Wear OS watch to another using a cloud backup and restore process. You can customize the set of files in your app that the system should include in a cloud backup, so that users only restore app data that’s meaningful to them."

Seamless data transfer: "Additionally, Wear OS 4 allows users to transfer their watch to a new phone without needing to perform a factory reset on the watch. They complete this process when setting up the new phone, as shown in the following flow below."

Other changes:

* Wear OS 4 removes the system UI for granting the SYSTEM_ALERT_WINDOW permission, which was available on some devices running Wear OS 3 and lower.

Wear OS 4 will arrive for the first-gen Pixel Watch later this year, and it's already available on Samsung's Galaxy Watch 4 and later. The updated Wear OS 4 emulator available through Android Studio Hedgehog doesn't support native 32-bit code, as Google wants developers to prepare for upcoming 64-bit only devices.

————————————————————————

Prepare your app for behavior changes in Wear OS 4 | Explore features in Wear OS 4

Since I'm not gonna have my own Pixel 8 for a while, I might as well put this out there so someone else can test it ASAP:

You might be able to enable DisplayPort Alternate Mode (ie. display output over USB-C) if you root the device. That's because it seems to be disabled at a software, not hardware, level unlike previous Pixels.

You can see here from a dump of husky (code-name for the Pixel 8 Pro) that the property persist.vendor.usb.displayport.enabled is set to 0.

This property is read by the init.zuma.usb.rc file, which is the USB config file for the Tensor G3-series devices (zuma). Since this property is set to 0, then DisplayPort is disabled.

Thus, if you root the phone and override this property (eg. via setprop persist.vendor.usb.displayport.enabled 1), then this may be enough to enable DisplayPort Alternate Mode.

There's even a separate display config for when DisplayPort is enabled, under /vendor/etc/displayconfig/display_port_0.xml.

Anyway, if you manage to get display output working using what I said, please let me know! If it does work, then that means Google can enable display output via an OTA update.

I'm aware that current carrier store models don't support display output, and that some are reporting that it doesn't as well (eg. below). However, it's true that they don't support it right now, but that doesn't mean it can never be enabled.

This has gotten a lot of attention, so let's clear some things up:

First of all, my source for this? It's mentioned right on Google's blog post.

Biometric authentication models are classified into three tiers: Class 3 (formerly Strong), Class 2 (formerly Weak), or Class 1 (formerly Convenience). While all 3 can be used to unlock a device, only Class 3 and Class 2 biometrics can integrate with BiometricPrompt (ie. authenticate within apps). Class 2, however, cannot integrate with the keystore.

Thus, the "highest Android biometric class" = Class 3. How did Google achieve this feat, considering the Pixel 8 only has a single front-facing RGB camera and not additional dedicated hardware like the older Pixel 4 or many iPhones?

In a separate blog post, Google credits "machine learning advancements" for the improvement.

I know some of you are still skeptical that the Pixel 8's face unlock is secure enough to be used for banking app sign-in and contactless payment authentication, so here's a bit of info about what it means for the Pixel 8's face unlock to be classified as Class 3.

A Class 3 biometric has a Spoof Acceptance Rate (SAR) between 0-7%, a False Acceptance Rate (FAR) of 1/50k, and a False Rejection Rate (FRR) of 10%.

Pixel, like every other OEM whose device has a biometric sensor, has to comply with the Biometric Security Program. The Biometric Security Program ensures that OEMs and biometric sensor vendors adhere to Google's criteria and testing requirements.

Pixel, like others, has to submit a Biometric Compliance Report (BCR) either directly to the Android team (self-certified) or through a 3P biometric security lab. We don't know which route they took, and yes ultimately it's "Google" who certifies/enforces these requirements, but this is something that's testable if you truly think it shouldn't be Class 3.

Android 14 adds support for Ultra HDR, a new type of JPEG file (JPEG_R) that can include a gainmap in its metadata so that the HDR version of an image can be rendered on HDR displays and the SDR version on SDR displays.

Separately, Android 14 also adds new APIs that lets third-party apps like Google Chrome support HDR images. Thanks to this, Google Chrome on Android 14 now not only supports these kind of relative HDR containers (like Google's Ultra HDR or Apple's EDR) but also absolute HDR containers (like 10-bit AVIF).

The result is stunning! Here are some photos of my Pixel 7 Pro running Chrome on Android 14 displaying 10-bit AVIF files.

—-

Thanks to Dylan Raga for his help in editing these images so you can see what it looks like on SDR displays.

Here are the websites that had those photos: [1] [2]

Here's the commit adding HDR image support in Chrome on Android 14. The issue tracker report.

The APIs that were added in Android 14 that make this possible include android.view.Display#getHdrSdrRatio, android.view.Display#registerHdrSdrRatioChangedListener, and android.view.SurfaceControlTransaction#setExtendedRangeBrightness(...)

Lastly, I should note that you'll need a device that supports SDR dimming on Android 14 for this to work. That currently includes the Pixel 7 and newer. This article explains what SDR dimming is.

In Android 14 QPR1 Beta 2, Google has revamped the "system update" page with a new UI specific to Pixels. The Pixel's new "software updates" page shows you whether your OS, Mainline version, and Pixel system apps are updated.

(Thanks to Nail Sadykov for the screenshots!)