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

Android's Bluetooth stack has been updated to meet Bluetooth 5.3 specifications, and the Bluetooth SIG has just certified that stack with LE Audio Unicast and Broadcast.

(Oddly, I don't see BASS or PBP in the list of supported profiles.)

Back in July, Android's Bluetooth stack was certified to meet the Bluetooth 5.2 spec with LE Audio Unicast support but not LE Audio Broadcast support.

One interesting tidbit from this listing is that the software build used for certification is Android 13 TD4A.220922. This could be an early build for testing things they plan to release as part of Android 13 QPR3.

Although Bluetooth became a Mainline module in Android 13 (though an optional one for OEMs), this updated BT stack won't be rolling out to Pixels as part of a Google Play System Update. This is because, as of now, the Bluetooth module isn't updatable.

EDIT:

To clarify, that doesn't mean the Bluetooth stack on Pixels won't be updated. It just means the update will happen through an OTA update instead of through a Google Play System Update, which is already the case for system components that aren't a part of a Mainline module.

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