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
The sources for SDK 34 are now available through Android Studio!
Note that this isn't the full Android 14 OS source code, so you can't build an OS image from this. But if you're a developer looking to update your app to use Android 14 APIs, this could help you during debugging.
Curiously, there are many hidden/system APIs included in this source code release, which doesn't make sense since these can't be used by third-party apps and aren't documented in the public SDK.
The Android 13 SDK sources also includes many APIs marked SystemAPI or hide, so I guess these just aren't removed. It's not like you can use them without reflection/swapping out android.jar anyway, though.
Note that this isn't the full Android 14 OS source code, so you can't build an OS image from this. But if you're a developer looking to update your app to use Android 14 APIs, this could help you during debugging.
Curiously, there are many hidden/system APIs included in this source code release, which doesn't make sense since these can't be used by third-party apps and aren't documented in the public SDK.
The Android 13 SDK sources also includes many APIs marked SystemAPI or hide, so I guess these just aren't removed. It's not like you can use them without reflection/swapping out android.jar anyway, though.
🔥23👍7
Mishaal's Android News Feed
The sources for SDK 34 are now available through Android Studio! Note that this isn't the full Android 14 OS source code, so you can't build an OS image from this. But if you're a developer looking to update your app to use Android 14 APIs, this could help…
Satellite communication APIs did make their way into Android 14, though everything is marked as "hide" so they're not available to third-party apps.
There's going to be a satellite service "demo mode". Supported datagrams include SOS messages and location sharing.
Satellite support will, of course, depend on the modem hardware in the device you're using. It's not something that's going to be supported by every device running Android 14.
There's going to be a satellite service "demo mode". Supported datagrams include SOS messages and location sharing.
Satellite support will, of course, depend on the modem hardware in the device you're using. It's not something that's going to be supported by every device running Android 14.
🔥26👍4