The way Android calculates how much storage space "system" files takes up is still totally faulty, even in Android 14!
Earlier this year, I inadvertently discovered how broken Android's storage calculations are when I posted a thread asking users to share screenshots of their storage statistics. Samsung users shared screenshots showing "system" files taking up 60+GB in size, causing many to believe that One UI was just that bloated.
However, this was just a misunderstanding by users due to the way OEMs advertise storage capacity (GB, ie. base 10) versus how Android sees the actual storage (GiB, ie. using base 2). So no, One UI isn't dramatically more bloated than other OSes.
Regardless, the way Android presented storage statistics to users was what caused them to be misled, so Samsung did the smart thing and fixed how they calculate the size of "system" files in their One UI 6 update, as Max Weinbach mentioned last month. However, Google did not fix this problem, which extends even beyond the GB/GiB conversion issue.
See, the way Android actually calculates "system" is totally nonsensical. Android just subtracts the storage attributed to everything else (images, videos, audio files, games, documents, and trash) from the amount of storage that's currently used up and attributes that to "system".
That means that Android considers as part of "system" any file that takes up space that isn't attributed to one of the other categories mentioned on the Storage page. Even if those files are user-created and located on /data/media, ie. absolutely not system files.
To demonstrate this, I used a shell command to create a 3GB file at /data/media/0 filled with random data, and Android in return thought that "system" grew 3GB larger in size. This is total nonsense, and it even affects how "Files by Google" calculates storage (perhaps because it uses the same attribution logic).
Earlier this year, I inadvertently discovered how broken Android's storage calculations are when I posted a thread asking users to share screenshots of their storage statistics. Samsung users shared screenshots showing "system" files taking up 60+GB in size, causing many to believe that One UI was just that bloated.
However, this was just a misunderstanding by users due to the way OEMs advertise storage capacity (GB, ie. base 10) versus how Android sees the actual storage (GiB, ie. using base 2). So no, One UI isn't dramatically more bloated than other OSes.
Regardless, the way Android presented storage statistics to users was what caused them to be misled, so Samsung did the smart thing and fixed how they calculate the size of "system" files in their One UI 6 update, as Max Weinbach mentioned last month. However, Google did not fix this problem, which extends even beyond the GB/GiB conversion issue.
See, the way Android actually calculates "system" is totally nonsensical. Android just subtracts the storage attributed to everything else (images, videos, audio files, games, documents, and trash) from the amount of storage that's currently used up and attributes that to "system".
That means that Android considers as part of "system" any file that takes up space that isn't attributed to one of the other categories mentioned on the Storage page. Even if those files are user-created and located on /data/media, ie. absolutely not system files.
To demonstrate this, I used a shell command to create a 3GB file at /data/media/0 filled with random data, and Android in return thought that "system" grew 3GB larger in size. This is total nonsense, and it even affects how "Files by Google" calculates storage (perhaps because it uses the same attribution logic).
🤬51👍28👎3🤔2😁1
Mishaal's Android News Feed
The way Android calculates how much storage space "system" files takes up is still totally faulty, even in Android 14! Earlier this year, I inadvertently discovered how broken Android's storage calculations are when I posted a thread asking users to share…
Samsung, for what it's worth, solved this problem too in One UI 6. I asked @akhilnarang to run the same ADB command on his Galaxy S23 running One UI 6, and "system" did not grow in size, only "other files" did. Which is exactly what should happen.
If you store a lot of games on your phone for emulation purposes, then those game files are likely erroneously being attributed to "system" as are any other file that's not recognized as falling into one of the other categories. I transferred a multi-gig .nsp file to my Pixel, and Android thought "system" grew by 12GB in size, lol!
This issue is going to make people freak out thinking their phone has a bug, leading to them unnecessarily taking their phone in/factory resetting. (I've already seen a few threads on Reddit of people freaking out by this/thinking it's a bug.)
Please fix this, Google!
If you store a lot of games on your phone for emulation purposes, then those game files are likely erroneously being attributed to "system" as are any other file that's not recognized as falling into one of the other categories. I transferred a multi-gig .nsp file to my Pixel, and Android thought "system" grew by 12GB in size, lol!
This issue is going to make people freak out thinking their phone has a bug, leading to them unnecessarily taking their phone in/factory resetting. (I've already seen a few threads on Reddit of people freaking out by this/thinking it's a bug.)
Please fix this, Google!
👍61❤10
TIL that Amlogic has a page (openlinux.amlogic.com) that lists what Android OS versions (both AOSP and Android TV/Google TV) they support for their chipsets. The table even confirms which Amlogic chipsets will get an updated BSP with Android 14 support.
According to this chart, Amlogic's S905X4(S905C2/S905C2L), S905Y4(S905C3), S805X2, A311D2, S905X3, S905X2, T963D4, T962D4, T965D4 (T982), T950D4, A311D2, and T982 will get Android 14 support, though oddly only the S905X2 and S905X3 are listed as getting the "ATV upgrade version".
(Just because your device has one of the chipsets listed as getting Android 14 support doesn't mean it'll actually get an update. That still depends on your device's OEM.)
(H/T AndroidTV_Rumor on Twitter.)
According to this chart, Amlogic's S905X4(S905C2/S905C2L), S905Y4(S905C3), S805X2, A311D2, S905X3, S905X2, T963D4, T962D4, T965D4 (T982), T950D4, A311D2, and T982 will get Android 14 support, though oddly only the S905X2 and S905X3 are listed as getting the "ATV upgrade version".
(Just because your device has one of the chipsets listed as getting Android 14 support doesn't mean it'll actually get an update. That still depends on your device's OEM.)
(H/T AndroidTV_Rumor on Twitter.)
👍29🔥1
The latest version of Google Play Services (v23.35.14) suggests you'll be able to locate some devices on the Find My Device network even when they're powered off or out of battery.
"
This lines up with what Kamila Wojciechowska reported back in April. She said that Google was working on adding support for locating Pixel devices even when they're powered off.
This would allegedly require hardware support to keep the Bluetooth chip running while the main processor and OS are shut down, as well as an updated HAL so that Play Services can send precomputed "Finder Network" keys to the device's Bluetooth chip so that it can continue broadcasting to other nearby devices on the FMDN.
"
Find My Device can also use the network to help locate this device when it’s powered off or out of battery."This lines up with what Kamila Wojciechowska reported back in April. She said that Google was working on adding support for locating Pixel devices even when they're powered off.
This would allegedly require hardware support to keep the Bluetooth chip running while the main processor and OS are shut down, as well as an updated HAL so that Play Services can send precomputed "Finder Network" keys to the device's Bluetooth chip so that it can continue broadcasting to other nearby devices on the FMDN.
👍74🔥10👎4🥰1
Android's Bluetooth stack is preparing to add support for using aptX Voice as a Super Wideband (SWB) codec. SWB enables higher-quality voice transmission over the Bluetooth handsfree profile (HFP). Currently, Android is set up to use LC3 over HFP for SWB.
aptX Voice is Qualcomm's proprietary voice codec that "[delivers] 32kHz voice call quality within the Bluetooth Handsfree Profile". The codec is supported on many smartphones & headsets with Qualcomm's chipsets & custom Bluetooth stack.
Android's Bluetooth stack will first check if the connected headset supports the LC3 codec, and if not, will then go with aptX Voice if the headset supports it. If the connection fails with LC3 and aptX Voice, then Android will fall back to CVSD.
It's worth noting that Qualcomm isn't upstreaming an aptX Voice encoder or decoder. Instead, they're working with Google to add support for their codecs to be used by Android's native Bluetooth stack so that, eventually, Google can mandate the use of Android's Bluetooth stack on all devices.
Android's Bluetooth stack was made an optional Mainline module in Android 13, but few devices are shipping Google's module. Google's WiFi module is becoming mandatory in Android 14 (likely only for newly launched devices), but it remains to be seen if/when Bluetooth will become mandatory as well.
For more context, refer to this post where I first talked about SWB support in Android's Bluetooth stack.
(Image credits: Qualcomm via Android Authority)
aptX Voice is Qualcomm's proprietary voice codec that "[delivers] 32kHz voice call quality within the Bluetooth Handsfree Profile". The codec is supported on many smartphones & headsets with Qualcomm's chipsets & custom Bluetooth stack.
Android's Bluetooth stack will first check if the connected headset supports the LC3 codec, and if not, will then go with aptX Voice if the headset supports it. If the connection fails with LC3 and aptX Voice, then Android will fall back to CVSD.
It's worth noting that Qualcomm isn't upstreaming an aptX Voice encoder or decoder. Instead, they're working with Google to add support for their codecs to be used by Android's native Bluetooth stack so that, eventually, Google can mandate the use of Android's Bluetooth stack on all devices.
Android's Bluetooth stack was made an optional Mainline module in Android 13, but few devices are shipping Google's module. Google's WiFi module is becoming mandatory in Android 14 (likely only for newly launched devices), but it remains to be seen if/when Bluetooth will become mandatory as well.
For more context, refer to this post where I first talked about SWB support in Android's Bluetooth stack.
(Image credits: Qualcomm via Android Authority)
👍36❤2
Google has released a second beta for Android TV 14! You can download it now through Android Studio. The build ID is UTT1.230802.001 and it has the September 2023 security patches.
I'll be digging through Android TV 14 Beta 2 soon, but if you want to see what I've already discovered in Android TV 14 Beta 1, check out this thread.
I'll be digging through Android TV 14 Beta 2 soon, but if you want to see what I've already discovered in Android TV 14 Beta 1, check out this thread.
👍25❤1
Android 14 blocks downgrading apps through the
Previously, the May 2023 security release included a patch that only blocked downgrading system apps to a version older than the one preloaded on the system image.
However, starting in Android 14 Beta 5.2, this applies to all apps, as shown below. I can confirm this was only introduced in a 5.X release, as I was able to downgrade both the WhatsApp and Reddit apps using the
According to one tipster, they first saw this behavior in Beta 5.2, which is why I'm saying it's Beta 5.2+. Also, since the One UI 6 beta is based on the latest Android 14 source code, it is also affected by this change.
Now in order to downgrade a non-system app, you'll need to either fully uninstall the app and then install the older version afterward or be sure always manually install the app using the
This change has its benefits, of course. Older versions of apps can have security issues or just not use the latest security/Android feature. Plus, generally it's not recommended to downgrade an app without clearing its data, as it can cause issues with mismatched settings/databases. That's why it makes sense why this restriction doesn't apply to apps marked debuggable, so that developers can continue to downgrade apps for testing purposes.
(Thanks to Fasten_M and Moshe E for the tip!)
adb install/pm install shell commands, unless the app is marked as debuggable.Previously, the May 2023 security release included a patch that only blocked downgrading system apps to a version older than the one preloaded on the system image.
However, starting in Android 14 Beta 5.2, this applies to all apps, as shown below. I can confirm this was only introduced in a 5.X release, as I was able to downgrade both the WhatsApp and Reddit apps using the
-d flag on Android 14 Beta 5 but was no longer able to do so after updating to Android 14 Beta 5.3. According to one tipster, they first saw this behavior in Beta 5.2, which is why I'm saying it's Beta 5.2+. Also, since the One UI 6 beta is based on the latest Android 14 source code, it is also affected by this change.
Now in order to downgrade a non-system app, you'll need to either fully uninstall the app and then install the older version afterward or be sure always manually install the app using the
--enable-rollback flag so you can use Android's built-in rollback manager feature.This change has its benefits, of course. Older versions of apps can have security issues or just not use the latest security/Android feature. Plus, generally it's not recommended to downgrade an app without clearing its data, as it can cause issues with mismatched settings/databases. That's why it makes sense why this restriction doesn't apply to apps marked debuggable, so that developers can continue to downgrade apps for testing purposes.
(Thanks to Fasten_M and Moshe E for the tip!)
👎57👍32🤔4🤡1
Is this our first look at the new remote for an upcoming Chromecast with Google TV refresh?
I found a video showcasing the new remote in the latest Android TV 14 beta.
The video shows an outline of a remote that bears resemblance to the current CCwGT remote, except that it has four large round buttons on the left, two large round buttons and a third large oblong button on the right, and a new⭐️button.
Attached to this post is a still image from the video. And for comparison, I also attached a photo of the current remote for a Chromecast with Google TV (HD).
If you're wondering what that new⭐️ button might be for, I previously discovered that Android TV 14 will add "magic button" customization settings that will let you choose whether pressing the button will "open a favorite app" or "view and switch inputs for TV or other devices".
Google hasn't confirmed that a new Chromecast is in the works, but 9to5Google reported back in January, based on evidence seen within the Google Home app, that a new device was in the works.
I found a video showcasing the new remote in the latest Android TV 14 beta.
The video shows an outline of a remote that bears resemblance to the current CCwGT remote, except that it has four large round buttons on the left, two large round buttons and a third large oblong button on the right, and a new⭐️button.
Attached to this post is a still image from the video. And for comparison, I also attached a photo of the current remote for a Chromecast with Google TV (HD).
If you're wondering what that new⭐️ button might be for, I previously discovered that Android TV 14 will add "magic button" customization settings that will let you choose whether pressing the button will "open a favorite app" or "view and switch inputs for TV or other devices".
Google hasn't confirmed that a new Chromecast is in the works, but 9to5Google reported back in January, based on evidence seen within the Google Home app, that a new device was in the works.
❤🔥30👍15
Nice, the Android Emulator will soon add a Pixel Tablet frame.
Screenshots look way better when shared in an appropriate device frame. I currently use frames for the Pixel 7, Pixel 7 Pro, Pixel Tablet, and Pixel Fold for all my images.
(Above, my "Pixel Tablet" [which is really just a Pixel 6a].)
Screenshots look way better when shared in an appropriate device frame. I currently use frames for the Pixel 7, Pixel 7 Pro, Pixel Tablet, and Pixel Fold for all my images.
(Above, my "Pixel Tablet" [which is really just a Pixel 6a].)
👍45❤1🥰1🤡1
Qualcomm has published documentation on how to prepare, optimize, and execute the Stable Diffusion model on Snapdragon 8 Gen 2-powered Android devices using Qualcomm's AI Engine Direct SDK.
They previously only had instructions on how to do this for Windows on Snapdragon devices, but now docs are live for Android as well.
You'll need a PC with a NVIDIA GPU running Ubuntu 20.04 (instructions are also available for WSL as well). There's a lot of steps involved, so I haven't tried setting this up myself yet. Let me know if you get it working!
They previously only had instructions on how to do this for Windows on Snapdragon devices, but now docs are live for Android as well.
You'll need a PC with a NVIDIA GPU running Ubuntu 20.04 (instructions are also available for WSL as well). There's a lot of steps involved, so I haven't tried setting this up myself yet. Let me know if you get it working!
👍46🔥1
Google has released a new version of the Android Studio IDE called Android Studio for Platform (ASfP).
Android Studio for Platform is the official IDE for Android platform development. It's intended for AOSP platform developers who build with the Soong build system.
ASfP supports C++, Kotlin, and Java and lets you configure your lunch target and platform modules from the project setup wizard.
In order to get started with ASfP, you'll need to have installed and initialized a Repo client on a Linux machine.
H/T @beachfuneral
Android Studio for Platform is the official IDE for Android platform development. It's intended for AOSP platform developers who build with the Soong build system.
ASfP supports C++, Kotlin, and Java and lets you configure your lunch target and platform modules from the project setup wizard.
In order to get started with ASfP, you'll need to have installed and initialized a Repo client on a Linux machine.
H/T @beachfuneral
🔥26👻18👍12❤6🎉2
The Play Integrity API will soon give developers a way to evaluate the "account activity" of a user. This new signal will help app and game developers detect "potentially risky and fraudulent traffic".
(Although the details of this EAP are apparently supposed to be confidential, the page documenting it all is just ... publicly available. [Thanks to @linuxct for the heads up!])
Play Integrity evaluates account activity "based on the presence and volume of store activity and the age of the accounts on the device." The API returns a level for the current user session that is "not linked to user or device identifiers." These levels include:
* UNEVALUATED: Account activity is not evaluated because the device is not trusted or the user does not have a Play app license
* UNUSUAL: Google Play store activity is unusual for at least one of the user accounts on the device. Google Play recommends checking that this is a real user.
* UNKNOWN: Google Play does not have sufficient store activity for the user account on the device. The account may be new, or it may lack activity on Google Play.
* TYPICAL (BASIC): Google Play store activity is typical for the user account or accounts on the device.
* TYPICAL (STRONG): Google Play store activity is typical for the user account or accounts on the device, with harder-to-replicate signals.
Google recommends using account activity as part of an overall anti-abuse strategy rather than as the sole determinant. Further, risky traffic should be challenged before high-value actions are allowed to proceed, rather than outright denying access.
The new account activity signal is currently under an early access program (EAP). As such, the features are in "active development and currently only available to select Play partners", such as developers in the Google Play Partner Program for Games.
(Although the details of this EAP are apparently supposed to be confidential, the page documenting it all is just ... publicly available. [Thanks to @linuxct for the heads up!])
Play Integrity evaluates account activity "based on the presence and volume of store activity and the age of the accounts on the device." The API returns a level for the current user session that is "not linked to user or device identifiers." These levels include:
* UNEVALUATED: Account activity is not evaluated because the device is not trusted or the user does not have a Play app license
* UNUSUAL: Google Play store activity is unusual for at least one of the user accounts on the device. Google Play recommends checking that this is a real user.
* UNKNOWN: Google Play does not have sufficient store activity for the user account on the device. The account may be new, or it may lack activity on Google Play.
* TYPICAL (BASIC): Google Play store activity is typical for the user account or accounts on the device.
* TYPICAL (STRONG): Google Play store activity is typical for the user account or accounts on the device, with harder-to-replicate signals.
Google recommends using account activity as part of an overall anti-abuse strategy rather than as the sole determinant. Further, risky traffic should be challenged before high-value actions are allowed to proceed, rather than outright denying access.
The new account activity signal is currently under an early access program (EAP). As such, the features are in "active development and currently only available to select Play partners", such as developers in the Google Play Partner Program for Games.
👍22🤡14👎9❤2
Google has deleted all code related to Fast Pair from AOSP.
Fast Pair is Google's proprietary standard for simplifying the first time discovery and pairing of nearby devices over Bluetooth Low Energy. It's available on most Android devices through the Google Play Services app.
However, Google Play Services is not available on devices shipped in China, which means that Android devices in China don't support Fast Pair. Some OEMs implemented their own Fast Pair-like pairing process, but this usually only works with audio products from their own brand.
To make Fast Pair ubiquitous on Android, Google aimed to bring Fast Pair to AOSP as part of the Connectivity Mainline module. The code for Fast Pair and the HalfSheet UX (the pop-up UI that appears when a device is discovered) was uploaded to AOSP with the release of Android 13, but this code was just deleted by Google a few days ago.
I'm not entirely sure why Fast Pair was deleted from AOSP, as I don't have access to the Issue Tracker reports linked in the commit. Perhaps it saw low adoption/interest from OEMs? If you know why it was removed, send me a DM!
Fast Pair is Google's proprietary standard for simplifying the first time discovery and pairing of nearby devices over Bluetooth Low Energy. It's available on most Android devices through the Google Play Services app.
However, Google Play Services is not available on devices shipped in China, which means that Android devices in China don't support Fast Pair. Some OEMs implemented their own Fast Pair-like pairing process, but this usually only works with audio products from their own brand.
To make Fast Pair ubiquitous on Android, Google aimed to bring Fast Pair to AOSP as part of the Connectivity Mainline module. The code for Fast Pair and the HalfSheet UX (the pop-up UI that appears when a device is discovered) was uploaded to AOSP with the release of Android 13, but this code was just deleted by Google a few days ago.
I'm not entirely sure why Fast Pair was deleted from AOSP, as I don't have access to the Issue Tracker reports linked in the commit. Perhaps it saw low adoption/interest from OEMs? If you know why it was removed, send me a DM!
😢59👍14🤬11🕊3🫡3🤔2🔥1🤡1