"What's new in Google System Updates" has been updated to list December 2022 changes. Notably:

* Beta support for adding a mobile driver's license issued by select US states to Google Wallet
* Inform the user if a tablet they're trying to cast to needs user interaction

At I/O 2022, Google said it was working with state governments in the U.S. and around the world to bring mobile driver's license support to Google Wallet. This feature is finally launching, though we still don't know which states will support it first.

Android has been ready for mobile driver's licenses for some time now (Identity Credential API was added in Android 11), so this has been a long time coming. The challenge has primarily been regulatory/political.

It's worth noting that the Android 14 VSR will require that launch devices support the Identity Credential HAL. This will enable mobile driver's licenses stored on Android devices to be even more securely stored.

—-

As for the tablet/cast change, given that the Pixel Tablet will likely double as a smart display, it's not surprising you'll be able to cast to it. However, there may be scenarios where you have to do something (unlock? change profiles?) before you can cast to it.

For December 2022's Android Feature Drop, Google's bringing:

- New styles in Google Photos' collage editor
- New holiday-themed emoji in Gboard's Emoji Kitchen
- A dedicated Reading Mode app
- YouTube home screen search widget
- Select a device to cast to from the Google TV app
- Share your digital car key within Google Wallet with other Pixel and iPhone users (and soon users on other select phones running Android 12+)
- New Wear OS tiles (favorite contacts, sunrise/sunset) & updated Keep app

Full details (and images/GIFs) in Google's blog post.

By the way, this Feature Drop is for all GMS Android users, not just Pixel users. (Google doesn't officially call it the "Android Feature Drop" anymore, but I like it so I'm still calling it that.) Next week, Pixel users will likely be treated to their Pixel Feature Drop for December 2022.

Google has announced that Android 13 is the first Android release where the majority of new code is written in a memory safe language. About 21% of all new native code added to Android 13 is written in Rust.

Support for Rust was introduced in Android 12. There are now approximately 1.5 million total lines of Rust code for new AOSP components such as Keystore2, the Ultra-wideband stack, DNS-over-HTTP/3, the Android Virtualization Framework, and more.

The drop in memory safety vulnerabilities (223 in 2019 to 85 in 2022) and the severity of vulnerabilities overall have been credited to Google's shift away from memory unsafe languages. 2022 is the first year where memory safety vulnerabilities aren't a majority of Android vulns.

Google's using Rust for new, low-level Android components & doesn't plan to convert existing code written in C/C++ (media, Bluetooth, NFC, etc.). However, they're improving the safety of Android's C/C++ code with things like the Scudo hardened allocator, HWASAN, GWP-ASAN, & KFENCE, as well as improved fuzzing.

And Google will continue to grow the use of Rust in the Android platform.

"We’re implementing userspace HALs in Rust. We’re adding support for Rust in Trusted Applications. We’ve migrated VM firmware in the Android Virtualization Framework to Rust. With support for Rust landing in Linux 6.1 we’re excited to bring memory-safety to the kernel, starting with kernel drivers."

I recommend reading the full blog post by Jeff Vander Stoep. It goes into a lot more detail!

Folks, this is bad news. Very, very bad. Hackers and/or malicious insiders have leaked the platform certificates of several vendors. These are used to sign system apps on Android builds, including the "android" app itself. These certs are being used to sign malicious Android apps!

Why is that a problem? Well, it lets malicious apps opt into Android's shared user ID mechanism and run with the same highly privileged user ID as "android" - android.uid.system. Basically, they have the same authority/level of access as the Android OS process!

(Here's a short summary of shared UID, from my Android 13 deep dive.)

The post on the Android Partner Vulnerability Initiative issue tracker shared SHA256 hashes of the platform signing certificates and correctly signed malware using those certificates. Thanks to sites like
VirusTotal and APKMirror, it's trivial to see who is affected...

So, for example, this malware sample. Scroll down to the certificate subject/issuer, and whose name do you see? The biggest Android OEM on the planet? Yeah, yikes.

Go to APKMirror and just search for the SHA256 hash of the corresponding platform signing certificate... Yeah, this certificate is still being used to sign apps.

That's just one example. There are others at risk, too.

In any case, Google recommends that affected parties should rotate the platform certificate, conduct an investigation into how this leak happened, and minimize the number of apps signed with the platform certificate, so that future leaks won't be as devastating.

Okay, so what are the immediate implications/takeaways for users?

- You can't trust that an app has been signed by the legitimate vendor/OEM if their platform certificate was leaked. Do not sideload those apps from third-party sites/outside of Google Play or trusted OEM store.

- This may affect updates to apps that are delivered through app stores if the OEM rotates the signing key, depending on whether or not that app has a V3 signature or not. V3 signature scheme supports key rotation, older schemes do not.

OEMs are not required to sign system apps with V3 signatures. The minimum signature scheme version for apps targeting API level 30+ on the system partition is V2. You can check the signature scheme using the apksigner tool.

Affected OEMs can still rotate the cert used to sign their system apps that have V2 signatures and then push an OTA update to deliver the updated apps. Then they can push app updates with that new cert, but devices that haven't received OTAs won't receive those app updates.

The leaked platform signing certificates can't be used to install compromised OTA updates, thankfully.

Statement from Google given to @9to5Google.

I think the best protection Google can offer is through Play Protect. If you install a new app that was signed by a leaked platform cert, Play Protect should be able to check if that app matches.

Satement from Samsung given to Android Police. As Android Police Founder Artem Russakovski and others have noted already, many of the malware samples submitted to VirusTotal are several years old.

Google has officially announced the rollout of end-to-end encryption for group chats in Messages. This "will be available to some users in the open beta program over the coming weeks." Also, Google says that you'll soon be able to react to RCS messages with any emoji.

Google has announced the release of Android 13 for TV today, but the new release is only available right now for the ADT-3 developer platform and the Android TV emulator.

If you want a full, detailed breakdown of what's new for TVs in Android 13, I've got you covered with this blog post.

Google is testing a "Send" shortcut in the Nearby Share bottom sheet that lets you quickly select files (using the Files by Google app) to share with others. This shortcut will appear when you tap the Quick Setting tile for Nearby Share.

Yes, you can already share files through Nearby Share. However, you have to open another app, select file(s) to share, hit share, & then pick Nearby Share. This cuts out some steps and makes the QS tile actually useful (before it just let you change visibility or open settings).

H/T t.me/google_nws

Google has been working on making it easier to do platform app development using Android Studio, and this latest code change in AOSP seems to bring them one step closer.

(AOSP code change in question: Export framework turbine stubs as android_stubs_private)

You're probably familiar with Android Studio, but you can't develop platform apps (like SystemUI) using it, at least not out of the box.

One of the issues is that only public APIs are available through the SDK that Android Studio downloads. Platform apps frequently call hidden/private/system APIs.

To solve this, one solution is to replace the SDK's android.jar file with one that contains all Android framework APIs, enabling platform app development through Android Studio.

(You can build your own android.jar to unlock all platform APIs by compiling AOSP and then extracting the JAR before it gets dexed. H/T @phhusson for that info. Another method is detailed here.)

Google's solution seems similar, except it's not replacing android.jar in the SDK path but instead adding an android_private_stubs JAR containing stubs for non-private APIs, so Android Studio won't throw a fit when you try to call them. More importantly, they'll probably maintain this so you won't need to manually create your own JAR for each Android release!

(There are other methods to enable AOSP platform app development on Android Studio, eg. a tool called AIDEGen is offered to configure your preferred IDE for platform app development.)

Back in March, the Android Studio team was hiring someone to help make Studio usable for Android OS development. This effort seems related to that role.

New features in the December 2022 Pixel Feature Drop:

- Clear Calling (Pixel 7)
- Speaker labels in Google Recorder (Pixel 6 onward)
- Free VPN by Google One (Pixel 7)
- New Curated Culture wallpapers (all)
- Unified search expands to all Pixels
- Safety Center (all)
- Live Translate now in Arabic, Persian, Swedish, Vietnamese, and Danish (Pixel 6 onward)
- Cough & snore detection now available for Pixel 6
- Better insights from Sleep Profile on Pixel Watch (requires Fitbit Premium)

In addition, Google says that it'll roll out spatial audio with head tracking support to the Pixel Buds Pro in January 2023. This will work with the Pixel 6 and 7 series.