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

Google will soon release "64-bit-only" images for some older Pixels, enabling you to test your app on a physical device supporting only 64-bit apps. The Android Emulator since Android 12 has been 64-bit-only.

If you have a Pixel 7, it's already configured to only run 64-bit apps. Note that the CPUs in all Pixels (including the Pixel 7) support the 32-bit Arm ISA, but (at least on Pixel 7) Google built Android without a 32-bit zygote but with 32-bit libraries in the firmware.

EDIT:

By "soon" I guess Google meant today! 64-bit-only images are now available for the Pixel 4a (5G), Pixel 5, Pixel 6, and Pixel 6 Pro.

Thanks to @NYJiggs82 for pointing this out!

EDIT 2:

Interestingly, unlike the Pixel 7's build, these new 64-bit-only images don't include any 32-bit system libraries! That reduces the size of each dynamic partition by a modest amount (about ~120MB in total).

EDIT 3:

If you dirty flash this build (ie. flash without wiping userdata), any apps without 64-bit support will be uninstalled automatically. Material Terminal was the only app that got uninstalled for me this way.

(Interestingly, if you search for a 32-bit app on Google Play on a 64-bit-only build, you'll see a message saying the app won't work for your device.)

Google plans to enable testing of the Privacy Sandbox on public mobile devices in early 2023 alongside the first stable API release in a future SDK extension.

Privacy Sandbox features and APIs are delivered to devices through the AdServices modular system component. An update to the AdServices module on Android 13 devices will bring the Privacy Sandbox to devices.

The "Next Up on the Privacy Sandbox" talk at the Android Dev Summit dives deep into Privacy Sandbox. I have a summary of what it entails here.

As for SDK Extensions, Google didn't really elaborate on/explain what it is, but I went into detail a bit in this article if you're interested.

EDIT:

More details on the beta for Privacy Sandbox for Android in a new blog post.

- Developers have to complete an enrollment process in order to utilize the ads-related APIs (Topics, FLEDGE, and Attribution Reporting)
- During the rollout, enrolled developers must join the early testers program.
- There'll be a closed beta for the SDK Runtime so devs can test RE SDK distribution.
- Developers will need to compile their solutions with an API level 33 SDK extension update