The first Android 13 QPR3 Beta will be released this coming Monday, March 13, according to the /u/androidbetaprogram account on Reddit.

Detailed instructions on how to migrate from the Android 13 QPR2 Beta to the upcoming Android 13 QPR2 stable release (which is "releasing this month") WITHOUT wiping data can be found in this Reddit post.

The rollout of the February 2023 Google Play System Update was completed earlier this week, but I only just got time to generate a changelog. Here are some notable changes:

* ART's new userfaultfd-based garbage collection algorithm is still not ready for public testing, but it might go live in the next train. [1] [2]

* Photo picker has been updated to support the "selected photos access" feature seen in Android 14, but PermissionController in the Feb. 2023 train doesn't support this. It's likely it won't be enabled for Android 13 devices anyway. [1]

* Safety Center has a new flag to control whether it can send notifications alerting you about potential security issues, such as reviewing apps with full device access (Accessibility). (I thought it already did this?) [1] [2]

If you want to see the full January 2023 --> February 2023 GPSU changelog yourself, you can do so here.

There's someone impersonating me and sending DMs to many of you here.

I will never send you a DM out of the blue, especially one that has nothing to do with Android in any way, so please disregard any DM that looks like it's coming from me. It's probably a scam.

Sorry for the inconvenience!

The March 2023 update is now rolling out for Pixel phones. The TQ2A.230305.008 build is based on the Android 13 QPR2 release. It also brings the latest Pixel Feature Drop, but Google's blog post on that hasn't gone live yet.

Here's a summary of available features (per device) in the new Pixel Feature Drop:

You can learn more in Google's blog post.

At the Google for Games Developer Summit, Google announced the following improvements to Google Play Games for PC, a build of Android for Windows PCs.

* Improved onboarding process
* Upcoming expansion to Japan and countries in Europe
* New games like Garena Free Fire, Ludo King, and MapleStory M
* Developers can now submit their existing mobile builds
* A new developer emulator for testing that allows for sideloading APKs or adjusting settings
* New release checklist to verify if you've done what's important before releasing your game
* Next-gen player IDs will roll out later this year that keep a user's player ID consistent across surfaces for any given game while letting them be unique across games

Also at the Google for Games Developer Summit, Google announced:

* Google Play's technical quality bar now uses new user-perceived crash and ANR metrics evaluated on a per-device (8%) and overall (1.09% for crash, 0.47% for ANR) basis. This was actually announced in October 2022 but seems to be more widely rolling out, as I noted earlier this month.

* Frame rate metrics for games in Android vitals have launched, and you can see them in the Play Console or with the Developer Reporting API

* Updates to Firebase Crashlytics to improve the quality of Unity stack traces, including Unity on-demand-fatal event reporting.

* New Adaptability APIs in the Android Game Development Kit to help games respond to changing device performance and thermal scenarios. The Android Dynamic Performance Framework adds a hinting library to send signals about your game's workload to the CPU. A new Thermal API to listen during runtime for when the device is about to thermally throttle.

* LiveOps tools have relaunched as promotional content and are available to more developers.

* Inactive custom store listings to target churned users.

* Machine translation in Play Console, uses Google Translate to translate your app's strings in over 8 languages including Simplified Chinese and Japanese.

Google's method of remotely bricking leaked/stolen phones (like the Pixel 7a that recently made the rounds) is actually open source!

They generate what's called a "brick OTA" that wipes the following partitions:

vbmeta
vbmeta_a
vbmeta_b
vbmeta_system_a
vbmeta_system_b
boot
boot_a
boot_b
vendor_boot
vendor_boot_a
vendor_boot_b
init_boot
metadata
super
userdata

This "brick OTA" is pushed to devices via GOTA (Google OTA) and can be installed on both "test-keys" and "release-keys" builds, but a serial number is required before a "brick OTA" can be installed on "release-keys" builds.

Many OEMs don't use GOTA, but a lot of them now do use update_engine, so Google's new automated "Android Brick OTA generator" tool might find some use outside of Google.

The Linux kernel's MGLRU feature will be enabled by default for all Android 14 kernels! (android14-5.15 and android14-6.1).

Benchmarks have shown that with MGLRU, overall app launch times improve, there are fewer overall process kills, kswapd CPU use decreases, etc.

"MGLRU has been tested and edge cases addressed on Android workloads; after which the MGLRU showed good results across various performance metrics. Enable the MGLRU as default memory reclaim in algorithm."

You can check if your kernel is compiled with MGLRU support (and whether it's enabled) with this command:

adb shell "cat /proc/config.gz | gunzip | grep 'CONFIG_LRU_GEN'"

CONFIG_LRU_GEN=y means it's available but not enabled

CONFIG_LRU_GEN_ENABLED=y means it's enabled

Google has been A/B testing this feature for the past few months, making it something they can enable using a DeviceConfig flag that can be enabled server-side, but AFAIK they haven't enabled this feature on any devices in production, though all Tensor Pixels can support it.

For more details on MGLRU, check out this earlier thread.

Google has just released Android 13 QPR3 Beta 1! This is the first beta release for what will be Android 13's final QPR that will be released to users in June 2023.

This QPR will have the least amount of user-facing changes of all but should be the most stable release of Android 13 yet.

You may see some of the minor QoL features/changes that were first seen in the Android 14 DP, so don't be surprised.

Follow this thread on Twitter to see what's new in Android 13 QPR3 Beta 1.

I got so bogged down in details that I sat on this story for months, but in the interest of the community, I'd like to confirm that the encoders for Qualcomm's proprietary aptX and aptX HD Bluetooth codecs are now part of AOSP.

Here's what this means for Android 👇

A few months back, I spotted a patch submitted to AOSP by a Qcom engineer called "add encoder for aptX and encoder for aptX HD source code." aptX and aptX HD codecs are proprietary to Qualcomm, so OEMs would previously acquire them directly from them.

I don't know what, if any, certification programs OEMs had to complete, or how much in licensing fees they had to pay, to obtain permission from Qualcomm to ship aptX and aptX HD encoders in their Android products. One article says that at least in 2014, there was a $6,000 one-time payment and ~$1 per-device fee for batches of up to 10k devices. That info came from Silicon Laboratories, a fabless semiconductor firm that designs many Bluetooth products.

The Wiki article on aptX, before my edit, falsely claimed that the aptX & aptX HD encoders were added to AOSP in A10 and could be freely used by OEMs. That was NOT true at the time. The claim was added in Dec. 2019 but was a misreading of a SoundGuys article on BT codecs.

What is true is that since Android 8.0, the Bluetooth A2DP stack added support for loading AAC, aptX, aptX HD, and LDAC codecs IF they were present in the build. As noted in the docs, "device manufacturers may need to obtain separate licenses and binary blobs for some proprietary audio codecs."

This is where I fell down a rabbit hole of licensing and patents. AAC isn't free? LDAC needs certification? Etc. I'm done with that rabbit hole. I even briefly tried using ChatGPT to help me draft some of this article, but the tone/voice just didn't feel right to me, lol.

Anyway, when it comes to aptX/HD, OEMs would obtain encoders compatible with AOSP right from Qualcomm.

eg. on Pixel phones prior to Android 13 QPR2, you could find precompiled aptX and aptX HD encoders as shared libraries in /system_ext/lib64. Starting in Android 13 QPR2, those shared libraries are no longer there, as they are compiled statically into the Bluetooth APEX.

I believe that going forward, any OEM that ships the Bluetooth APEX in their AOSP-based project will have the aptX and aptX HD encoders available in their end product by default.

There is even a new MTS test (Mainline Test Suite) test for this. Of course, just because there is source code for something doesn't make it open source. That depends on the license.

To clarify this, I reached out directly to Qualcomm a few months back, and got the following statement (for context, in early Nov. 2022):

“We made the decision a few months back to include the encoders for classic aptX and aptX HD in the Android Open Source Project. The technology is known the world over as THE superior audio codec for wireless BT audio, and we have worked closely with both Google and individual OEM’s over the years to include these codecs in Android-based products. We are excited to say that under license from Qualcomm, these encoders are indeed now available under AOSP pursuant to the CLA’s in place. 

As aptX codecs continue to be the leader in delivering superior audio quality, and with our introduction of Snapdragon Sound in March 2021, Qualcomm is committed to ensuring we deliver premium audio experiences, the lowest possible latencies, and the best connectivity solutions available. As per our usual business processes, the licensing of aptX, Snapdragon Sound and the underlying technologies, will continue to remain unchanged apart from contributing the aptX and aptX HD encoders to AOSP."

And just to be extra extra sure, I asked Qualcomm to explicitly name the license and what products are covered:

"There are inbound and outbound licenses to the project of course. Once officially approved by Google - which we expect in the coming days since these were just recently submitted - the encoders will be offered under the outbound AOSP (Apache) license.”

“The purpose of the contribution is to enable people to distribute the encoders as part of their finished products. The only Qualcomm products included in this release for Android are aptX and aptX HD ENCODERS. All other aptX products require a license direct from Qualcomm."

So there you go, you no longer need to undergo certification or pay a licensing fee to Qualcomm if you want to include an aptX and/or aptX HD encoder in your ANDROID product, so long as you utilize the code in AOSP licensed under Apache v2.0.

This is great news for hobbyist custom ROM developers as well, as previously they'd have to just rip the shared libraries from a precompiled build (with questionable legality). Now you can just compile them from AOSP sources.

And yes, they do work as shared libraries if you change the blueprint to compile them as such.

Here's the source code in AOSP if you're interested:

Encoder for aptX | Encoder for aptX High Definition

Since I know most of you have devices that support aptX and aptX HD already, you're wondering why you should care. Well, for most users, this doesn't matter. It's a change that affects OEMs for the most part.

Surprisingly there are some devices that don't have either aptX or aptX HD, though. My NVIDIA SHIELD TV, for example, only supports aptX but not aptX HD.

Several users are reporting that the "ring & notification volume" sliders have been suddenly split into "ring volume" and "notification volume" in Android 14 DP2. This is WITHOUT them flipping any flags, which was previously required to enable separate ring/notification volume.

Google added this feature in Android 13 QPR2, as I first reported in December. The feature is gated by a DeviceConfig flag ("volume_separate_notification" under the "systemui" namespace), but it appears Google remotely toggled the flag for users on DP2.

If you are on Android 13 QPR2 or later, you can manually enable this feature by sending the following shell command:

device_config put systemui volume_separate_notification true

It's possible this was a mistake and will be reverted soon. It's hard to tell, because it was a server-side change with no announcement from Google. If Android 14 adds a settings toggle to enable/disable linking the volumes, then we'll know if it's intentional or not.

You can view the code changes implementing this feature in AOSP: [1] [2] [3]

Google could also add a settings toggle in a future Android 13 QPR3 beta, since it's not like this feature requires making any changes to the API surface which is frozen. I'll keep an eye out.

Please keep this feature around and add a setting toggle for it, Google. People clearly want this feature!

—-

EDIT: The DeviceConfig flag was removed in the stable QPR2 release. It is present in QPR3 Beta 1 and Android 14 DP1/DP2, however. H/T Aswin A S