Haven't seen this reported anywhere yet, but the Tensor G2 in the Pixel 7 series introduced a custom DSP.

A Googler on the Google Taiwan silicon team says that image processing has been improved with their new DSP, and that it'll continue to improve with future Pixel Feature Drops.

The custom DSP seems to be code-named "Aurora". It's also referred to as a "GXP" device in some places, though I don't know what GXP stands for.

When Google originally launched Google Play Games for PC, the system image they shipped was based on Android 11. After the beta went live in the US and other countries a few days back, I noticed they updated the system image to be based on Android 12L.

(Google Play Games for PC builds declare the com.google.android.play.feature.HPE_EXPERIENCE feature, which is how you can distinguish between it from other devices.)

A recently disclosed vulnerability gives any attacker with physical access to your Pixel phone the ability to unlock it. All they need is a SIM card with a PIN and the SIM's PUK code.

The vulnerability is tracked with CVE-2022-20465, and patches are available for AOSP 10-13. This bug has been fixed with the 2022-11-01 SPL.

Here's a video from the author showcasing the lockscreen bypass on a Pixel 6.

It looks like the new MediaTek Dimensity 9200 is NOT a 64-bit only SoC, despite initial reporting otherwise. MediaTek confirmed to Android Authority that only the performance cores are 64-bit only. Buried in the Dimensity 9200's product page, you'll see it says the chipset "provides the first 64-bit exclusive Armv9 Performance Cores for smartphones..." but under "CPU Bit" it says "64-bit Exclusive" without clarifying further.

(Compare this with the page for the Dimensity 9000, which has just "64-bit" under the "CPU Bit" part of the specifications table.)

The D9200 has 1x X3, 3x A715, and 4x A510 cores. The X3 and A715 only support AArch64. The original A510 also only supports AArch64, but the refresh (A510r1) can optionally support AArch32. Given the clarification given to Android Authority, we can assume the A510 cores are A510r1.

Google recently announced that the Pixel 7 is the first 64-bit only Android phone. All CPU cores in Tensor G2, however, do actually support AArch32. It's just that Google built their Android image with a 64-bit only Zygote, so 32-bit apps won't run. Theoretically, I guess you could compile a custom ROM for the Pixel 7 that supports both 64-bit and 32-bit Zygote spawning, re-enabling 32-bit app support on the Pixel 7. That won't work when future chipsets feature CPUs that don't support AArch32 instructions in the first place.

One solution to this might be to integrate a 32-bit to 64-bit Arm binary translator, like Tango. Tango can be integrated into builds as a kernel module compatible with the GKI. A reference image based on GrapheneOS is available for the Pixel 6 if you want to try Tango out. (Tango isn't really necessary for the Pixel 6 or Pixel 7, but it'll be neat to see how this works on devices with next-gen Armv9 chipsets in the future).

Next week, Qualcomm is launching the Snapdragon 8 Gen 2. According to @nullby, its 3x A510 cores are the R1 variant with 32-bit support enabled. This isn't confirmed yet of course, but if true, the new Snapdragon will also support running 32-bit apps (on those 3 cores).

Devices that launch with Android 14 and which feature Armv9 CPUs may be required to not support 32-bit apps, though. So whatever MTK and QCOM's next flagships are, they may not support 32-bit apps (unless this requirement gets punted which can happen).

According to @nullby, the Android 13-based build available in the Dimensity 9200's BSP ships with 32-bit libraries and zygote by default. Same as with the Snapdragon 8 Gen 2. So 32-bit support is still here for another generation.

Project Treble was announced >5 yrs ago alongside Android 8.0, and one of its biggest changes was the ability to boot a generic build of Android (a GSI).

The first device the community booted a GSI on was the Huawei Mate 9, a device that launched with Android 7.0 but Huawei Treblized with their 8.0 update.

Nearly 5 yrs later, @phhusson has booted an Android 13 GSI on the Mate 9. This is really impressive considering Google phased out legacy GSI support with Android 12, so devices with 8.0/8.1 vendor software shouldn't be able to boot AOSP 12+ GSIs.

Google's GSI is all about validating Project Treble compatibility, while phh's project is all about extending device compatibility and support for as long as possible. I don't know if the Treble team envisioned the community ever taking it this far!

If you have an old device with simple hardware lying around (and it's bootloader unlockable), breath some new life into it with a GSI! Many GSIs take phh's near-AOSP build and add a lot of customizations on top.

As I mentioned before, it's possible to reenable 32-bit app support on the Pixel 7 because Google shipped the build with 32-bit libraries still but disabled the 32-bit zygote process from spawning. To reenable 32-bit apps on the Pixel, you need root access.

This post by @ThomasKing2014 on Twitter shows the Pixel 7 (panther) with the 32-bit zygote process running. To do this, they needed to modify 'ro.zygote', 'ro.vendor.product.cpu.abilist', and 'ro.vendor.product.cpu.abilist32'.

ro.zygote=zygote64_32
ro.vendor.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
ro.vendor.product.cpu.abilist32=armeabi-v7a,armeabi

A patch file for Magisk 24.3 is available on GitHub. This patch adds code to native/jni/init/rootdir.cpp that modifies vendor/build.prop with these properties.

I thought making a script that runs during the post-fs-data stage (which happens before zygote starts) using resetprop to set these properties would be enough, but it doesn't work. If you get it working without patching Magisk, let me know!

EDIT: Great writeup on how to re-enable 32-bit app support on the Pixel 7 by XDA user namelesswonder. Sadly, it still seems like you need to patch Magisk itself because there's no other way to modify the requisite props early enough in the boot process.

Here's Android's new Photo Picker working in Google Keep. Except Keep hasn't been updated to support it, and I haven't flipped any Keep flags to make this happen.

How does this work? The Photo Picker is being updated to work with existing apps - without any code changes needed.

The actual mechanism Google is using to make this Photo Picker takeover happen is quite simple, but also quite clever!

If you want the full breakdown of how this works, check out this article.