This app lets you change your Bluetooth codec settings without diving into Developer Options.
You probably already know this, but you can change various Bluetooth audio-related settings like the codec, sample rate, and more by going to Settings > System > Developer options.
You shouldn't have to use this menu as your Android device and headphones should negotiate the best settings, but sometimes, they just don't. For example, every time I connect my WH-1000XM3s to the Nothing Phone 2, it defaults to aptX HD even though I enabled LDAC on the headphones through Sony's app. But there's a bug in Nothing OS 2.0 that prevents you from changing the Bluetooth codec in Settings (all the options are blank)!
But thanks to this app, called Bluetooth Codec Changer, I can change the codec to LDAC! The app also has a long list of extra features, available through a one-time in-app purchase (currently $2.99, normally $9.99), such as automatic codec switching, profile saving, widgets to change profiles, and more.
(Thanks to aborne25 for bringing this app to my attention! I should've mentioned this in my other post on Cast Receiver, but neither this thread nor that one were "sponsored" in any way, and I'm not in contact with the developers of either app.)
You probably already know this, but you can change various Bluetooth audio-related settings like the codec, sample rate, and more by going to Settings > System > Developer options.
You shouldn't have to use this menu as your Android device and headphones should negotiate the best settings, but sometimes, they just don't. For example, every time I connect my WH-1000XM3s to the Nothing Phone 2, it defaults to aptX HD even though I enabled LDAC on the headphones through Sony's app. But there's a bug in Nothing OS 2.0 that prevents you from changing the Bluetooth codec in Settings (all the options are blank)!
But thanks to this app, called Bluetooth Codec Changer, I can change the codec to LDAC! The app also has a long list of extra features, available through a one-time in-app purchase (currently $2.99, normally $9.99), such as automatic codec switching, profile saving, widgets to change profiles, and more.
(Thanks to aborne25 for bringing this app to my attention! I should've mentioned this in my other post on Cast Receiver, but neither this thread nor that one were "sponsored" in any way, and I'm not in contact with the developers of either app.)
👍36❤5⚡1🔥1
Google is preparing big upgrades for Android's taskbar
With the Android 14 QPR1 release (December 2023 Pixel Feature Drop), the taskbar could get some new, very useful features!
Details available exclusively on Patreon.
With the Android 14 QPR1 release (December 2023 Pixel Feature Drop), the taskbar could get some new, very useful features!
Details available exclusively on Patreon.
👍47💩16👎6🔥3🥱1
TIL that Samsung's Remote Test Lab also offers their Wear OS watches for testing!
Samsung currently only offers 8 Galaxy Watch 6 series devices in the RTL, though, so you may have to wait for one to become available.
For those of you who don't know, Remote Test Lab lets you remotely test your apps on REAL Samsung hardware, including their latest Galaxy Tab S9 series, Galaxy Z Flip 5, and Galaxy Z Fold 5.
This is a pretty useful service as buying all of these devices costs quite a bit of money! Galaxy Watch 6 + Tab S9 + Z Flip 5 + Z Fold 5 = ~$3900.
It would be nice if Samsung updated some of their S23 series devices in RTL with the One UI 6 beta, so developers without an S23 can remotely test their app on Samsung's Android 14 release as soon as possible.
Samsung currently only offers 8 Galaxy Watch 6 series devices in the RTL, though, so you may have to wait for one to become available.
For those of you who don't know, Remote Test Lab lets you remotely test your apps on REAL Samsung hardware, including their latest Galaxy Tab S9 series, Galaxy Z Flip 5, and Galaxy Z Fold 5.
This is a pretty useful service as buying all of these devices costs quite a bit of money! Galaxy Watch 6 + Tab S9 + Z Flip 5 + Z Fold 5 = ~$3900.
It would be nice if Samsung updated some of their S23 series devices in RTL with the One UI 6 beta, so developers without an S23 can remotely test their app on Samsung's Android 14 release as soon as possible.
👍26❤4👀4
Google is working on a new developer option in Android that will swap out your device's Linux kernel with one that uses a 16K page size. Compiling the kernel to use 16K pages could provide a significant performance improvement but also break many apps.
A page is a fixed-length contiguous block of virtual memory. Android currently uses a 4K page size, while iOS and macOS use a 16K page size. Some workloads benefit significantly by using a larger page size, like kernel compilation.
But although ARM64 Linux binaries are compatible with 4K, 16K, and 64K pages by default, many native apps and Android OS components that assume a 4K page size might just break. (These comments by a lead Asahi Linux developer go into a lot more detail about the potential challenges.)
This is why Google is incrementally experimenting with 16K page size support in Android. They've been working on compiling the kernel with a 16K page size and fixing various issues since last October, but late last week, a Googler submitted a series of patches to AOSP (that have not yet been merged) that add a "developer option for booting with 16K pages."
If/when these patches are merged, a new "enable 16K pages" toggle will be added under Settings > System > Developer Options. When you toggle this option, Android will warn you that "some applications may not be compatible with this mode." Android will then call update_engine - the system OTA service - to swap the kernel to a 16K compatible one.
I have no idea if/when this developer option will land, nor whether Google will actually go through with changing to a 16K page size compatible kernel. If they do, it won't be for a while and the transition will be slow given how much might break.
A page is a fixed-length contiguous block of virtual memory. Android currently uses a 4K page size, while iOS and macOS use a 16K page size. Some workloads benefit significantly by using a larger page size, like kernel compilation.
But although ARM64 Linux binaries are compatible with 4K, 16K, and 64K pages by default, many native apps and Android OS components that assume a 4K page size might just break. (These comments by a lead Asahi Linux developer go into a lot more detail about the potential challenges.)
This is why Google is incrementally experimenting with 16K page size support in Android. They've been working on compiling the kernel with a 16K page size and fixing various issues since last October, but late last week, a Googler submitted a series of patches to AOSP (that have not yet been merged) that add a "developer option for booting with 16K pages."
If/when these patches are merged, a new "enable 16K pages" toggle will be added under Settings > System > Developer Options. When you toggle this option, Android will warn you that "some applications may not be compatible with this mode." Android will then call update_engine - the system OTA service - to swap the kernel to a 16K compatible one.
I have no idea if/when this developer option will land, nor whether Google will actually go through with changing to a 16K page size compatible kernel. If they do, it won't be for a while and the transition will be slow given how much might break.
🔥40👍19❤4
Nearby Share targets may soon start appearing directly in the Android system share sheet! This would save you a tap as you'd be able to select a device to send to without opening the full Nearby Share menu.
In order to reduce clutter in the share sheet, this will likely only show your devices and not any others. Also, your devices seem to appear in the top row alongside other Direct Share targets.
I haven't seen any other reports of this rolling out yet, so let me know if you see this on your device.
Screenshot credits: @nailsad_eleos
In order to reduce clutter in the share sheet, this will likely only show your devices and not any others. Also, your devices seem to appear in the top row alongside other Direct Share targets.
I haven't seen any other reports of this rolling out yet, so let me know if you see this on your device.
Screenshot credits: @nailsad_eleos
❤48👍22🔥7
Google is announcing that Assistant will soon no longer support smartwatches running Wear OS 2. You'll need to upgrade to a newer watch that runs Wear OS 3 (and that supports Google Assistant).
I just got this notification on my TicWatch Pro 3 - anyone else also get this?
(The time on the notification says 2:36AM, but I didn't check my watch's notifications until now.)
Update: Assistant is already disabled for me. The Assistant icon no longer appears for me when I swipe to the left page. RIP.
I just got this notification on my TicWatch Pro 3 - anyone else also get this?
(The time on the notification says 2:36AM, but I didn't check my watch's notifications until now.)
Update: Assistant is already disabled for me. The Assistant icon no longer appears for me when I swipe to the left page. RIP.
🤬47😢16👍10🤣4🗿3👎1
TIL that some OEMs just ... didn't implement Android 13's per-app language feature, which lets users set a different language for each app!
OnePlus didn't add it in OxygenOS 13 (and I presume neither did OPPO in ColorOS 13) nor did Xiaomi in MIUI 14.
It's always hard to tell when a certain feature Google adds to Android is going to be available across all devices. I do my best to find out by looking at whether the feature is Pixel exclusive first (Google introduces some features they never explicitly say are Pixel only) then whether there's going to be a CDD/GMS requirement regarding it.
As far as I can tell, per-app language settings isn't mentioned anywhere in the CDD/GMS reqs, but I'm pretty sure most OEMs implemented it. I know Samsung, ASUS, and Nothing have, for example.
As for why OnePlus/OPPO and Xiaomi didn't implement this feature, I can only guess. Perhaps they encountered some issue they couldn't resolve or maybe they felt it wasn't worth supporting (it's in AOSP though so it's there by default).
In the case of OnePlus and I presume OPPO as well, at least they plan on adding this feature in their Android 14 update! Frequent OnePlus tipster @OneNormalUsername discovered that the closed beta of OxygenOS 14 has the per-app language feature. (Credits for the screenshot of per-app language settings in OxygenOS 14 go to Aamir Siddiqui.)
In the case of Xiaomi, I asked frequent tipster @kacskrz about it, but they said they aren't sure if the feature is coming in Android 14-based builds of MIUI. However, the per-app language settings are still there and can be launched manually through an activity launcher.
As an alternative, you can use the "Language Selector" app which uses the Shizuku library to gain shell user privileges to access the locale manager CLI.
OnePlus didn't add it in OxygenOS 13 (and I presume neither did OPPO in ColorOS 13) nor did Xiaomi in MIUI 14.
It's always hard to tell when a certain feature Google adds to Android is going to be available across all devices. I do my best to find out by looking at whether the feature is Pixel exclusive first (Google introduces some features they never explicitly say are Pixel only) then whether there's going to be a CDD/GMS requirement regarding it.
As far as I can tell, per-app language settings isn't mentioned anywhere in the CDD/GMS reqs, but I'm pretty sure most OEMs implemented it. I know Samsung, ASUS, and Nothing have, for example.
As for why OnePlus/OPPO and Xiaomi didn't implement this feature, I can only guess. Perhaps they encountered some issue they couldn't resolve or maybe they felt it wasn't worth supporting (it's in AOSP though so it's there by default).
In the case of OnePlus and I presume OPPO as well, at least they plan on adding this feature in their Android 14 update! Frequent OnePlus tipster @OneNormalUsername discovered that the closed beta of OxygenOS 14 has the per-app language feature. (Credits for the screenshot of per-app language settings in OxygenOS 14 go to Aamir Siddiqui.)
In the case of Xiaomi, I asked frequent tipster @kacskrz about it, but they said they aren't sure if the feature is coming in Android 14-based builds of MIUI. However, the per-app language settings are still there and can be launched manually through an activity launcher.
As an alternative, you can use the "Language Selector" app which uses the Shizuku library to gain shell user privileges to access the locale manager CLI.
😡27👍12💩7❤2🤔2
Android 14 is introducing a new safety feature called "headphone loud sound alerts". This is REALLY important. Way too many people suffer from hearing loss because they listened to music at excessively loud volumes for too long.
I know I talked about headphone loud sound alerts before, but the last time I did, I didn't have:
a) Google's source code for the feature.
b) The $452 standards doc this feature is based on.
Thanks to Google's SDK 34 release and a source for providing the doc, I now have both!
This time around, I also did the totally sane thing and tested the feature out by playing a 10-hour long YouTube video of air horn sounds.
Before you comment that your phone already has this feature, please read the article! All the details about it as well as how it compares to the existing safe media volume feature you're probably familiar with can be found in the Android Police article, so give it a read!
I know I talked about headphone loud sound alerts before, but the last time I did, I didn't have:
a) Google's source code for the feature.
b) The $452 standards doc this feature is based on.
Thanks to Google's SDK 34 release and a source for providing the doc, I now have both!
This time around, I also did the totally sane thing and tested the feature out by playing a 10-hour long YouTube video of air horn sounds.
Before you comment that your phone already has this feature, please read the article! All the details about it as well as how it compares to the existing safe media volume feature you're probably familiar with can be found in the Android Police article, so give it a read!
👍46❤11👎6🎉4
Google has now confirmed the work profile changes I first reported on last month. ie. Android 14 now actually pauses - instead of turns off - your work profile. This means your work profile remains running, though apps are suspended.
This new behavior is now mentioned on the "what's new in enterprise in Android 14" page. App developers should read this page to get ready for this change, as there are some things you need to be aware of when it comes to notifications and how to listen for changes to work profile status.
For the full rundown on this change and what it means for users, refer to this article I wrote last month.
(Thanks to @AssembleDebug for notifying me that Google updated their page!)
This new behavior is now mentioned on the "what's new in enterprise in Android 14" page. App developers should read this page to get ready for this change, as there are some things you need to be aware of when it comes to notifications and how to listen for changes to work profile status.
For the full rundown on this change and what it means for users, refer to this article I wrote last month.
(Thanks to @AssembleDebug for notifying me that Google updated their page!)
👍16🔥9❤2😢1
This is something a lot of people aren't aware of - just how many tests Google requires OEMs to run before they can push an Android software build through!
Off the top of my head, there are 9:
* CTS (Compatibility Test Suite)
* VTS (Vendor Test Suite)
* CTS-on-GSI (Compatibility Test Suite on Generic System Image)
* GTS (Google Test Suite)
* CTS-V (Compatibility Test Suite Verifier)
* ITS (Image Test Suite, technically part of CTS-V)
* BTS (Build Test Suite)
* STS (Security Test Suite)
* MTS (Mainline Test Suite)
Collectively, this series of tests is referred to as xTS for short.
Not all of these have to be re-run with every subsequent OTA, to be fair. But these are just the test suites, which don't cover ALL the requirements OEMs have to follow, which are laid out in the CDD (Compatibility Definition Document), GMS Requirements (Google Mobile Services Requirements), VSR (Vendor Software Requirements), and other documents.
By the way, each test by itself can take anywhere from hours to days, so the entire testing process can end up taking several days. There are some tricks to speed these up, like sharding (parallelizing test by running them on multiple devices), though.
There are also programs like GMS Express that can help cut down on testing time. SoC vendors like MediaTek and UNISOC offer BSPs that pass xTS already, reducing the time it takes to get a build out.
(Fun fact: OEMs don't submit their test results directly to Google. Instead, Google contracts out the certification process to 3PLs [third-party labs].)
Off the top of my head, there are 9:
* CTS (Compatibility Test Suite)
* VTS (Vendor Test Suite)
* CTS-on-GSI (Compatibility Test Suite on Generic System Image)
* GTS (Google Test Suite)
* CTS-V (Compatibility Test Suite Verifier)
* ITS (Image Test Suite, technically part of CTS-V)
* BTS (Build Test Suite)
* STS (Security Test Suite)
* MTS (Mainline Test Suite)
Collectively, this series of tests is referred to as xTS for short.
Not all of these have to be re-run with every subsequent OTA, to be fair. But these are just the test suites, which don't cover ALL the requirements OEMs have to follow, which are laid out in the CDD (Compatibility Definition Document), GMS Requirements (Google Mobile Services Requirements), VSR (Vendor Software Requirements), and other documents.
By the way, each test by itself can take anywhere from hours to days, so the entire testing process can end up taking several days. There are some tricks to speed these up, like sharding (parallelizing test by running them on multiple devices), though.
There are also programs like GMS Express that can help cut down on testing time. SoC vendors like MediaTek and UNISOC offer BSPs that pass xTS already, reducing the time it takes to get a build out.
(Fun fact: OEMs don't submit their test results directly to Google. Instead, Google contracts out the certification process to 3PLs [third-party labs].)
👍40😱6🤔2
You may eventually be able to use your Android TV as a Bluetooth speaker
I've spotted evidence that suggests you'll be able to turn your Android TV/Google TV device into a Bluetooth speaker for your phone or other Bluetooth-enabled devices.
Currently, most Android TV/Google TV devices only support acting as a Bluetooth audio source device, but that could change in a future release.
Full details available exclusively to Patrons/X subscribers.
I've spotted evidence that suggests you'll be able to turn your Android TV/Google TV device into a Bluetooth speaker for your phone or other Bluetooth-enabled devices.
Currently, most Android TV/Google TV devices only support acting as a Bluetooth audio source device, but that could change in a future release.
Full details available exclusively to Patrons/X subscribers.
👍37🔥5
"Crossdrop is a partial implementation of Google's Nearby Share in Flutter for macOS, iOS and Linux"👀
Developer PlutoHDDev is working on porting Google's Nearby Share to more platforms, starting with Linux first!
Crossdrop is still a work-in-progress, so it's not feature-complete nor stable enough for production use. It's based on NearDrop, a previous port of Nearby Share to macOS, made by developer grishka.
CrossDrop on GitHub | Documentation on Google's Nearby Share protocol | My previous post on NearDrop
Developer PlutoHDDev is working on porting Google's Nearby Share to more platforms, starting with Linux first!
Crossdrop is still a work-in-progress, so it's not feature-complete nor stable enough for production use. It's based on NearDrop, a previous port of Nearby Share to macOS, made by developer grishka.
CrossDrop on GitHub | Documentation on Google's Nearby Share protocol | My previous post on NearDrop
❤48👍11🔥11
Heads up to any AOSP platform developers: Google is apparently deprecating AIDEGen.
In its place, Google is recommending "ASfP", which apparently stands for "Android Studio for Platform".
This is casually mentioned in the README file for the new RemoteAuth Mainline module (if you're wondering what that this, see this Patron-only post).
AIDEGen, for those unaware, enables you to configure your preferred IDE (like IntelliJ or Android Studio) for platform app development.
There are some problems with using AIDEGen, though, according to one experienced platform developer I've spoken to. These include:
* When you start a new target, it needs to "recompile" makefiles. This could take a few minutes.
* You need to run Android Studio locally, which can be annoying if you're trying to build on a remote server.
* To run a change, the "run" button in Android Studio might not work so instead you need to go back to the console.
Google has been working on making it easier to use Android Studio for platform app development, but I'm not entirely sure if ASfP will solve all these issues since I don't have access to the documentation that Google linked.
In its place, Google is recommending "ASfP", which apparently stands for "Android Studio for Platform".
This is casually mentioned in the README file for the new RemoteAuth Mainline module (if you're wondering what that this, see this Patron-only post).
AIDEGen, for those unaware, enables you to configure your preferred IDE (like IntelliJ or Android Studio) for platform app development.
There are some problems with using AIDEGen, though, according to one experienced platform developer I've spoken to. These include:
* When you start a new target, it needs to "recompile" makefiles. This could take a few minutes.
* You need to run Android Studio locally, which can be annoying if you're trying to build on a remote server.
* To run a change, the "run" button in Android Studio might not work so instead you need to go back to the console.
Google has been working on making it easier to use Android Studio for platform app development, but I'm not entirely sure if ASfP will solve all these issues since I don't have access to the documentation that Google linked.
👍18🥱1