Qualcomm just announced the Snapdragon 8 Gen 2. There are a bunch of great articles covering what's new (this article by Android Authority is a good read) but I wanted to point out two things:

- It has an AV1 decoder, the first for a Snapdragon chip
- It still supports 32-bit apps, with its 2x A710 cores and 3x A510r1 cores

AV1 support was expected, but the CPU configuration is quite strange. It has a 1 x 2 x 2 x 3 configuration, comprised of 1x Cortex-X3, 2x Cortex-A715, 2x Cortex-A710, and 3x Cortex-A510r1.

The X3 and A715 cores only support AArch64 ISA, but the A710 and A510r1 all support AArch32. The reason to have 2x A715 and 2x A710 instead of just 4x A715 is ostensibly so 32-bit apps will perform better, as 32-bit apps will be able to run on all three Silver cores (A510r1) and two Gold cores (A710) instead of just the three Silver cores.

The image attached to this post shows the full specs of this chipset.

EDIT:

Another thing worth pointing out is the software: The Snapdragon 8 Gen 2 launches with a BSP that supports Android 13. Because it's a chipset under Google Requirements Freeze, its vendor software won't be updated alongside the system update to Android 14-16.

This is nothing new, though, as this has been the policy since GRF launched alongside the first Qualcomm SoC to launch with an Android 11 BSP (the 888).

Version 22.44.16 of Google Play Services is reportedly causing some devices to reboot to recovery, with the only fix being a factory reset. This affects both managed and unmanaged devices, so be sure to keep an eye on your devices and update them to the latest version of Play Services to be safe!

H/T Jason Bayton on Twitter

The Nearby Share button in Android 13's clipboard editor overlay is starting to roll out. This was shown off at Google I/O 2022, but it's finally started to appear on at least some users' devices. Are you seeing this button yet?

Another upcoming change that's related to Nearby Share is its placement in Android's share sheet. According to the "what's new in Google System Updates" page, Nearby Share "will now show in the first row as a sharing option."

This change hasn't rolled out yet, but you can see it in action in this screenshot from
@AssembleDebug on Twitter. The "Nearby" option will disappear from the top and will only be shown among other share sheet targets. (I don't know why this change is being made.)

EDIT: Devices running Android 11+ have to place the Nearby Share chip in the action row of the share sheet, so consistency in placement isn't an issue here.

However, perhaps Google saw that this wasn't being used very much? On Android 6-10 devices where the AOSP share sheet doesn't support the action row, Nearby Share is already shown in the first row/page of the share sheet.

So if Google gets rid of the chip in the action row, it'd just make the experience consistent across Android 6-13.

(Alternatively, Google isn't getting rid of the Nearby Share chip in the action row, but instead will leave it in place AND add the share target entry point shown in the first row. This would give users on Android 11+ two ways to access Nearby Share from the share sheet.)

Starting May 2023, Google Play will require that apps built for Android TV and Google TV be uploaded as Android App Bundles (AAB) with app archiving support enabled. This is great news since TVs often have far less storage than smartphones/tablets. TV apps that haven't transitioned to AAB may be hidden from users on "the TV surface".

Android TV & Google TV support for app archiving wasn't mentioned in the original announcement for this feature, but I spotted hints for this back in June.

If you want to know how app archiving works under the hood, this blog post I wrote covers what you need to know about the new "archived APK" format it relies on.

And if you want to see what app archiving looks like on mobile, here's a demo.

(Full details on today's announcement are in this blog post.)

Waze is apparently coming to Android Automotive OS as soon as next month! An admin on the Waze Suggestion Box forum said they're working on making it available, and a business development manager from Renault said they're expecting it to launch by the end of this year.

It's not confirmed if it'll be available through Google Play for all cars running AAOS with Google Automotive Services, but I hope it won't be exclusive to a particular brand.

H/T /u/Eluryh on Reddit

OnePlus now joins Samsung in promising 4 platform upgrades and 5 years of security updates, though this is only for "selected devices" in 2023 and security updates will be "bi-monthly".

Extended software support is mostly a matter of cost and resources. With initiatives like Project Treble, GKI, Project Mainline, and GRF, Android has become more and more modular, and thus easier (and cheaper) to upgrade.

There is a caveat, though. GRF, or Google Requirements Freeze, makes it *more* difficult for OEMs to support N+4 letter upgrades, as they'll have to upgrade the vendor software from N to N+4 on their own. It's not impossible, just more work. We'll have to see how long it takes OnePlus to roll out the 4th letter upgrade for these "selected devices".

Google promises 3 letter upgrades and 5 years of security updates - both generally day 1 releases - which is less than what Samsung and now OnePlus promise. Hopefully other OEMs (and Google) follow suit in offering extended software support soon.

Google is working on making OTA updates faster. A new set of patches has been submitted to AOSP that speed up OTAs on devices that use the virtual A/B with compression update mechanism. Combined, these improvements bring a full OTA install time from ~23 minutes to ~13 minutes!

The first improvement is to batch write COW operations in a cluster. The second improvement is to use two threads to compress the snapshot.

Android's OTA update mechanisms can get a bit confusing, but this article I wrote a few weeks back explains all of them (including the newer virtual A/B with compression that's used on Pixels and is being improved here!)

H/T Luca Stefani for the heads up

"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.