Two features that are missing on Pixel but are present in stock Android:
1) The ability to control the volume of speaker groups while casting.
2) The ability to expand streams to more cast devices from the media output switcher (stream expansion).
Both can be enabled, though!
Let me explain each issue in more detail before I show the fix.
1) You can't adjust a speaker group's volume while casting. Both the volume button & slider only control your phone's media volume unless you're in the app that's casting. Other phones like the Nothing Phone 2 can.
If you don't have root access, your only workaround is to adjust the individual volumes through the media output switcher, which to be fair is pretty easy. The workaround for #2, though, is more annoying.
2) When you cast music to any speaker and then open the media output switcher, you should be able to select additional devices to cast to. eg. on my Z Fold 5 and Nothing Phone 2, I'm already casting to two Cast devices, but I can select a third to cast to: My Bose Soundbar 700.
You're unable to do this on Pixel. I asked around and checked numerous Pixels on Android 13 and 14, and none of them can do this. So the only workaround on Pixel would be to create speaker groups ahead of time rather than on demand.
Both features are intentionally disabled on Pixels likely as a result of the Sonos lawsuit. This article talks about the cast volume changes, while this article talks about stream expansion.
If you have root access, you can enable both of these features on your Pixel phone!
For #1, install this Magisk Module I made a while back. It overrides the value of
For #2, you'll need to override the
1) The ability to control the volume of speaker groups while casting.
2) The ability to expand streams to more cast devices from the media output switcher (stream expansion).
Both can be enabled, though!
Let me explain each issue in more detail before I show the fix.
1) You can't adjust a speaker group's volume while casting. Both the volume button & slider only control your phone's media volume unless you're in the app that's casting. Other phones like the Nothing Phone 2 can.
If you don't have root access, your only workaround is to adjust the individual volumes through the media output switcher, which to be fair is pretty easy. The workaround for #2, though, is more annoying.
2) When you cast music to any speaker and then open the media output switcher, you should be able to select additional devices to cast to. eg. on my Z Fold 5 and Nothing Phone 2, I'm already casting to two Cast devices, but I can select a third to cast to: My Bose Soundbar 700.
You're unable to do this on Pixel. I asked around and checked numerous Pixels on Android 13 and 14, and none of them can do this. So the only workaround on Pixel would be to create speaker groups ahead of time rather than on demand.
Both features are intentionally disabled on Pixels likely as a result of the Sonos lawsuit. This article talks about the cast volume changes, while this article talks about stream expansion.
If you have root access, you can enable both of these features on your Pixel phone!
For #1, install this Magisk Module I made a while back. It overrides the value of
config_volumeAdjustmentForRemoteGroupSessions.For #2, you'll need to override the
DynamicSession__enable_stream_expansion_transfer_for_allowlisted_groups and DynamicSession__enable_stream_expansion_transfer_for_audio_app Phenotype flags under com.google.android.gms.cast.👍33❤6🔥1
This flew under the radar, but Android 13's unified Security & Privacy settings (AKA the "Safety Center") rolled out to several non-Pixel devices in the last few months!
So far, I've seen it on:
* Nokia X20
* Nothing Phone 1
* Nothing Phone 2
* OnePlus 11
For a bit of context, Google announced the unified security & privacy settings back at I/O 2022. With the launch of the Pixel 7 in October, Google said this feature would be "coming soon first to Pixel devices later this year, and other Android phones soon after."
The unified security & privacy settings page indeed rolled out to other Pixel devices with their December 2022 Pixel Feature Drop, but there wasn't any word on when we'd see it on other devices running Android 13.
The feature has quietly begun to show up on non-Pixel devices. The Nothing Phone 1 received it with its OS 1.5.4 update, while the Phone 2 shipped with it, as I noted in my Nothing OS 2.0 review.
Meanwhile, the OnePlus 11 added the feature with its OxygenOS 13.1.0.580 update (H/T @OneNormalUsername). This isn't mentioned in the official changelog, but users have reported it on their forums.
As for the Nokia X20, I'm not sure when it received it, but a user on my Telegram group said they had it and posted a screenshot of it.
Safety Center is part of the Permission Mainline module, specifically the PermissionController app. Its configuration is provided by the SafetyCenterResources app. Its presence is controlled by two flags:
So far, I've seen it on:
* Nokia X20
* Nothing Phone 1
* Nothing Phone 2
* OnePlus 11
For a bit of context, Google announced the unified security & privacy settings back at I/O 2022. With the launch of the Pixel 7 in October, Google said this feature would be "coming soon first to Pixel devices later this year, and other Android phones soon after."
The unified security & privacy settings page indeed rolled out to other Pixel devices with their December 2022 Pixel Feature Drop, but there wasn't any word on when we'd see it on other devices running Android 13.
The feature has quietly begun to show up on non-Pixel devices. The Nothing Phone 1 received it with its OS 1.5.4 update, while the Phone 2 shipped with it, as I noted in my Nothing OS 2.0 review.
Meanwhile, the OnePlus 11 added the feature with its OxygenOS 13.1.0.580 update (H/T @OneNormalUsername). This isn't mentioned in the official changelog, but users have reported it on their forums.
As for the Nokia X20, I'm not sure when it received it, but a user on my Telegram group said they had it and posted a screenshot of it.
Safety Center is part of the Permission Mainline module, specifically the PermissionController app. Its configuration is provided by the SafetyCenterResources app. Its presence is controlled by two flags:
config_enableSafetyCenter and safety_center_is_enabled. config_enableSafetyCenter defaults to true in AOSP, however safety_center_is_enabled is a DeviceConfig flag that's controlled server-side by Google Play Services. Meaning, Google decides which devices should have the feature.👍18❤2🤔2🔥1
How does Google decide what devices to enable the feature on? I reached out to Google last week to find out but haven't heard back yet, however, OnePlus may have let slip a key detail: It may be required for certain "tiers" of Android devices.
While they were looking through logcat on the OnePlus 10 Pro,
@OneNormalUsername discovered this interesting line:
This suggests that "Tier 3" devices under v4.0 of the Revenue Sharing Agreement between Google & OnePlus must support Safety Center. I'm not sure if Tier 3 is defined similarly in all RSAs between Google & OEMs, but this may explain why it's only available on some devices.
The Nothing Phone 2 is categorized as a "Premier" tier GMS device, and it does ship with a ton of optional Google app prebuilts, so it could also fall under similar terms. No way for me to find out, though!
In any case, it's possible this feature will become more broadly available in Android 14, as Safety Center is enabled by default in AOSP builds of Android 14. It likely won't be mandatory, though, and I'm guessing many OEMs will disable it or implement their own (like Samsung).
While they were looking through logcat on the OnePlus 10 Pro,
@OneNormalUsername discovered this interesting line:
07-28 15:55:43.563 1000 5011 5011 W SafetyCenterManagerWrap: isEnabled: version is not RSA4.0 T3, don't support safety center.This suggests that "Tier 3" devices under v4.0 of the Revenue Sharing Agreement between Google & OnePlus must support Safety Center. I'm not sure if Tier 3 is defined similarly in all RSAs between Google & OEMs, but this may explain why it's only available on some devices.
The Nothing Phone 2 is categorized as a "Premier" tier GMS device, and it does ship with a ton of optional Google app prebuilts, so it could also fall under similar terms. No way for me to find out, though!
In any case, it's possible this feature will become more broadly available in Android 14, as Safety Center is enabled by default in AOSP builds of Android 14. It likely won't be mandatory, though, and I'm guessing many OEMs will disable it or implement their own (like Samsung).
👍18🔥1🥰1👏1
Google is now publicly publishing a Wear OS Security Bulletin!
This new bulletin details security vulnerabilities affecting the Wear OS platform.
The August 2023 bulletin is live and patches are available for Wear OS 3 (based on Android 11) and Wear OS 4 (based on Android 13).
Wear OS Security Bulletin - August 2023
(This is actually the second Wear OS Security Bulletin. The first one wasn't public, though.)
This new bulletin details security vulnerabilities affecting the Wear OS platform.
The August 2023 bulletin is live and patches are available for Wear OS 3 (based on Android 11) and Wear OS 4 (based on Android 13).
Wear OS Security Bulletin - August 2023
(This is actually the second Wear OS Security Bulletin. The first one wasn't public, though.)
👍30👏5🔥1
I'm pretty busy today with personal stuff so I can't offer much of my own analysis/commentary, but I still think you should be aware of these announcements:
* Android 14 introduces first-of-its-kind cellular connectivity security features
* Smoothing out the scrolling experience in Chrome on Android
* Your RCS conversations are now fully end-to-end encrypted
* An update on Chrome Security updates – shipping security fixes to you faster
* Android 14 introduces first-of-its-kind cellular connectivity security features
* Smoothing out the scrolling experience in Chrome on Android
* Your RCS conversations are now fully end-to-end encrypted
* An update on Chrome Security updates – shipping security fixes to you faster
Google Online Security Blog
Android 14 introduces first-of-its-kind cellular connectivity security features
Posted by Roger Piqueras Jover, Yomna Nasser, and Sudhi Herle Android is the first mobile operating system to introduce advanced cellular...
👍53❤4🔥2👏1
The Pixel Fold supports spatial audio over wired headphones just like the Pixel 6 and Pixel 7 series do, but unlike those devices, it also supports spatial audio over the phone speaker!
On Google's support page for spatial audio, it's noted that this feature is "Pixel Fold only". Indeed, only felix has the system prop "persist.vendor.audio.spatializer.speaker_enabled" set to true, which surfaces this option.
Google adjusted the audio configuration of the Pixel Fold to enable support for spatial audio over phone speakers while taking into account different hinge angles.
I assume the speakers/speaker placement also accounts for why this is only enabled on the Fold. In any case, if you have a Pixel Fold, let me know how spatial audio over speakers compares to over headphones!
(Screenshot credits: @SageSushi)
On Google's support page for spatial audio, it's noted that this feature is "Pixel Fold only". Indeed, only felix has the system prop "persist.vendor.audio.spatializer.speaker_enabled" set to true, which surfaces this option.
Google adjusted the audio configuration of the Pixel Fold to enable support for spatial audio over phone speakers while taking into account different hinge angles.
I assume the speakers/speaker placement also accounts for why this is only enabled on the Fold. In any case, if you have a Pixel Fold, let me know how spatial audio over speakers compares to over headphones!
(Screenshot credits: @SageSushi)
❤20👍10🔥2👏1
In Android 14, you can manually revoke the USE_FULL_SCREEN_INTENT permission from apps so they can't send you full-screen notifications.
Later this year, Google Play will auto revoke this permission from newly installed apps that don't provide calling or alarm functionality!
Later this year, Google Play will auto revoke this permission from newly installed apps that don't provide calling or alarm functionality!
"Starting with Android 14, apps allowed to use this [USE_FULL_SCREEN_INTENT] permission are limited to those that provide calling and alarms only. The Google Play Store revokes default USE_FULL_SCREEN_INTENT permissions for any apps that don't fit this profile.For context on the USE_FULL_SCREEN_INTENT permission and what Android 14 changes, refer to this post I made earlier on the subject.
These changes are landing at the end of 2023. This permission remains enabled for apps installed on the phone before the user updates to Android 14. Users can turn this permission on and off."
🎉33👍7🔥2❤1🥰1🙏1
What was once thought to be an oversight in Android 13 has now been marked as intended behavior:
Most apps will no longer be allowed to retrieve the user's wallpaper. Only apps that request the highly sensitive MANAGE_EXTERNAL_STORAGE permission can do so on Android 13+.
Okay, this is going to require a bit of explaining to make sense.
As part of Google's ongoing Scoped Storage efforts, Android 13 split the READ_EXTERNAL_STORAGE permission into 3 new permissions: READ_MEDIA_AUDIO, READ_MEDIA_VIDEO, and READ_MEDIA_IMAGES.
This was done so that apps that only need to access your images, for example, could do so without also getting access to your audio or video files.
The problem is that the standard API to retrieve the user's wallpaper, WallpaperManager#getDrawable(), still required the app calling it to hold the READ_EXTERNAL_STORAGE permission...which could no longer be granted to newly installed apps on Android 13 targeting API 33.
And requesting one of the new READ_ permissions doesn't help, as these aren't sufficient to use the API.
There were only 3 workarounds:
1) Request the broader MANAGE_EXTERNAL_STORAGE permission, which Google Play audits/heavily restricts the use of. A lot of apps won't qualify.
2) Ask the user to manually grant READ_EXTERNAL_STORAGE via 'adb shell pm grant'. (This works because the permission still exists in Android but Permission Controller doesn't let apps targeting API 33+ request it.) This is not a good workaround to promote to the average user.
3) Continue targeting an older Android version, like Android 12. To maintain compatibility, apps running on Android 13+ that target Android 12 can request READ_EXTERNAL_STORAGE. If the app updates to target Android 13, it'll retain the permission.
This is also not a great workaround as some libraries may require Android 13. Plus, starting August 31, all new apps & updates to existing apps must target Android 13 to be allowed on Google Play.
Most apps will no longer be allowed to retrieve the user's wallpaper. Only apps that request the highly sensitive MANAGE_EXTERNAL_STORAGE permission can do so on Android 13+.
Okay, this is going to require a bit of explaining to make sense.
As part of Google's ongoing Scoped Storage efforts, Android 13 split the READ_EXTERNAL_STORAGE permission into 3 new permissions: READ_MEDIA_AUDIO, READ_MEDIA_VIDEO, and READ_MEDIA_IMAGES.
This was done so that apps that only need to access your images, for example, could do so without also getting access to your audio or video files.
The problem is that the standard API to retrieve the user's wallpaper, WallpaperManager#getDrawable(), still required the app calling it to hold the READ_EXTERNAL_STORAGE permission...which could no longer be granted to newly installed apps on Android 13 targeting API 33.
And requesting one of the new READ_ permissions doesn't help, as these aren't sufficient to use the API.
There were only 3 workarounds:
1) Request the broader MANAGE_EXTERNAL_STORAGE permission, which Google Play audits/heavily restricts the use of. A lot of apps won't qualify.
2) Ask the user to manually grant READ_EXTERNAL_STORAGE via 'adb shell pm grant'. (This works because the permission still exists in Android but Permission Controller doesn't let apps targeting API 33+ request it.) This is not a good workaround to promote to the average user.
3) Continue targeting an older Android version, like Android 12. To maintain compatibility, apps running on Android 13+ that target Android 12 can request READ_EXTERNAL_STORAGE. If the app updates to target Android 13, it'll retain the permission.
This is also not a great workaround as some libraries may require Android 13. Plus, starting August 31, all new apps & updates to existing apps must target Android 13 to be allowed on Google Play.
👍31🔥4👎2❤1👏1
I talked about this issue last year when Zachary Wander brought it to my attention. At the time, it seemed like it was an oversight, so developers filed a report on the Issue Tracker. Unfortunately, Android 13 released with no fix/update on the issue...
On May 2, 2023, though, Google marked the issue with "Status: Won't Fix (Intended Behavior)".
Their reasoning:
Google doesn't say why they require apps to request the sensitive MANAGE_EXTERNAL_STORAGE permission instead of something less far-reaching like READ_MEDIA_IMAGES, but there is a valid reason for limiting which apps can access your wallpaper. As this blog post points out, it's possible to create a cross-app identifier by checking the user's wallpaper. Also, many people use a personal photo as their wallpaper, which you may not want untrusted apps to have access to.
As some developers point out on the Issue Tracker, though, there are some potentially useful things that this change makes more difficult to do for third-party launchers.
(H/T to Zachary again for first spotting this change a few months back on Mastodon, and to this XDA article for reminding me of this.)
Sample app demonstrating how the Android 13 update affects getDrawable. Sample app demonstrating that MANAGE_EXTERNAL_STORAGE allows apps to retrieve the wallpaper.
On May 2, 2023, though, Google marked the issue with "Status: Won't Fix (Intended Behavior)".
Their reasoning:
"We discussed the behavior with our product and engineering team and they were supportive of keeping the API only accessible to privileged system apps."
The Android API docs have been updated to reflect the new behavior. Android 14's new READ_WALLPAPER_INTERNAL permission has a protection level of signature|privileged, so it can only be granted to privileged system apps.Google doesn't say why they require apps to request the sensitive MANAGE_EXTERNAL_STORAGE permission instead of something less far-reaching like READ_MEDIA_IMAGES, but there is a valid reason for limiting which apps can access your wallpaper. As this blog post points out, it's possible to create a cross-app identifier by checking the user's wallpaper. Also, many people use a personal photo as their wallpaper, which you may not want untrusted apps to have access to.
As some developers point out on the Issue Tracker, though, there are some potentially useful things that this change makes more difficult to do for third-party launchers.
(H/T to Zachary again for first spotting this change a few months back on Mastodon, and to this XDA article for reminding me of this.)
Sample app demonstrating how the Android 13 update affects getDrawable. Sample app demonstrating that MANAGE_EXTERNAL_STORAGE allows apps to retrieve the wallpaper.
👍15😢1