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

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.