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.

Spatial audio with head tracking is available starting in Android 13 QPR1, thanks to the new audio pipeline architecture and sensor framework integration.

The Pixel 6 and 7 series received QPR1 yesterday, but spatial audio with head tracking support isn't available yet when connected to the Pixel Buds Pro as Google says this feature will roll out next month. It's likely the reason for the wait is that the Pixel Buds Pro will need a firmware update.

For head tracking to work, the headset needs to report head pose information following Android's Head Tracker HID Protocol. Also, a low-latency codec needs to be used, as head-tracking latency must not >150ms for the experience to be good. Google will likely be using Opus; QPR1 added support for it over A2DP.

However, it's not clear if the Buds Pro currently support Opus decoding, and a firmware update may be needed to enable this as well as support for sending out that head pose information.

When it does roll out, Google says that spatial audio will initially be supported with movies from Netflix, YouTube, Google TV, and HBOMax that have 5.1 or higher audio tracks. Google recommends using content marked as Dolby audio, 5.1 or Dolby atmos.

Head tracking isn't enabled by default, though. You'll have to navigate to Settings > Connected devices > Pixel Buds Pro > Settings > Head tracking to turn it on, as shown below.

This is why I wasn't too sad when I bricked my ADT-3. I had already heard the ADT-4 was coming with these specs 😆

This upgrade is long overdue. Android TV 10 mandated launch devices to support AV1 decoding, which the ADT-3 does not support. More recently, Android TV 13 added a bunch of features/APIs related to terrestrial broadcasting, so a device like this is needed to test.