One of the BIGGEST downsides of importing a phone is the fact there's no guarantee carriers in your country will allow your device to access VoLTE/VoWiFi on their network, even if the phone is technically capable.
Fortunately for Pixel 6 & later, there's a workaround!
A Korean developer released an open source app called "Pixel IMS" that enables VoLTE (and with version 1.1.2 VoWiFi) on select Pixel devices in "unsupported" regions. Best part? It DOESN'T REQUIRE ROOT.
Although the GitHub README mentions LG U+ (a Korean carrier), users on Reddit's /r/GooglePixel subreddit are reporting success on Vodafone Albania, Telcel in Mexico, Chile, Austria, Orange Romania, China Mobile, Hungary, etc.
It's both hilarious (and sad) that this even works. It makes use of Shizuku, a library that enables app processes to run with shell privileges, to call Android's internal telephony.ICarrierConfigLoader.overrideConfig() API.
The app uses this API to forcefully return "true" for KEY_CARRIER_VOLTE_AVAILABLE_BOOL, KEY_CARRIER_VT_AVAILABLE_BOOL, and KEY_CARRIER_WFC_IMS_AVAILABLE_BOOL. The fact this works so easily is great, but highlights how silly the allowlisting is in the first place ๐
EDIT: To be clear, I don't think a simple allowlist is the ONLY reason your phone can't/isn't allowed to use VoLTE/VoWiFi on certain networks. Testing IS important, and making sure IMS settings are appropriate for the carrier is also important, but VoLTE/VoWiFi should be at a point where it just works for everyone. As carriers shut down 2G and 3G networks, it needs to Just Work, especially if you're roaming somewhere. Relax the allowlists, please!
Fortunately for Pixel 6 & later, there's a workaround!
A Korean developer released an open source app called "Pixel IMS" that enables VoLTE (and with version 1.1.2 VoWiFi) on select Pixel devices in "unsupported" regions. Best part? It DOESN'T REQUIRE ROOT.
Although the GitHub README mentions LG U+ (a Korean carrier), users on Reddit's /r/GooglePixel subreddit are reporting success on Vodafone Albania, Telcel in Mexico, Chile, Austria, Orange Romania, China Mobile, Hungary, etc.
It's both hilarious (and sad) that this even works. It makes use of Shizuku, a library that enables app processes to run with shell privileges, to call Android's internal telephony.ICarrierConfigLoader.overrideConfig() API.
The app uses this API to forcefully return "true" for KEY_CARRIER_VOLTE_AVAILABLE_BOOL, KEY_CARRIER_VT_AVAILABLE_BOOL, and KEY_CARRIER_WFC_IMS_AVAILABLE_BOOL. The fact this works so easily is great, but highlights how silly the allowlisting is in the first place ๐
EDIT: To be clear, I don't think a simple allowlist is the ONLY reason your phone can't/isn't allowed to use VoLTE/VoWiFi on certain networks. Testing IS important, and making sure IMS settings are appropriate for the carrier is also important, but VoLTE/VoWiFi should be at a point where it just works for everyone. As carriers shut down 2G and 3G networks, it needs to Just Work, especially if you're roaming somewhere. Relax the allowlists, please!
๐35๐ฅ1๐1๐ซก1
This media is not supported in your browser
VIEW IN TELEGRAM
Last year, I reported that Google was hiring someone to help OEMs deploy Android features that use Android's Context Hub Runtime Environment. Today, Google announced that the OnePlus 11 uses CHRE to improve the responsiveness of Fast Pair discovery!
Although Google's blog post calls CHRE a "new technology", it's been around for a while (since Android 7). The Pixel's car crash detection feature, for example, makes use of CHRE, as I documented in this blog post.
The blog post also says that they're looking to use CHRE to "boost other Android features like Nearby Share, improving responsiveness when it comes to sharing files with friends from your phone." Notably, The Pixel 7 series ships with a "nearby" nanoapp.
Although Google's blog post calls CHRE a "new technology", it's been around for a while (since Android 7). The Pixel's car crash detection feature, for example, makes use of CHRE, as I documented in this blog post.
The blog post also says that they're looking to use CHRE to "boost other Android features like Nearby Share, improving responsiveness when it comes to sharing files with friends from your phone." Notably, The Pixel 7 series ships with a "nearby" nanoapp.
๐19๐1
The Galaxy S23 might be Samsung's first Android device to use EROFS for its read-only partitions! The Galaxy Z Fold 4 and previous Samsung flagships use F2FS for their read-only partitions.
Left: DiskInfo on Z Fold 4
Right: DiskInfo on S23
(Screenshot credits: Chris Wedel)
I don't have an S23 or Z Fold 4 for comparison, but if you do, you can check out the partitions yourself using the DiskInfo app or by using the Linux 'mount' command.
EROFS is a performant and space efficient file system for read-only partitions developed by Huawei that has gained popularity among other Android OEMs like Xiaomi and OPPO. It has been supported in Linux since 5.4.
In fact, Google once planned to make it mandatory for Android 13 launch devices to use EROFS for their read-only partitions. However, they relaxed this requirement and now only require kernel support to pass VTS/VSR-13.
Google was going to use EROFS for its own Pixel 7 series as well, but they reverted this decision quite late in the development cycle when they discovered a regression in app launch times for some apps like Google Photos.
If you want to learn more about EROFS, check out Google's talk at LPC 2022, or read my blog post on it.
Thanks to HN user chenxiaolong for first bringing this change to my attention. They examined the firmware of the European S23 Ultra and found that all dynamic partitions under 'super' (system, system_ext, product, vendor, odm) were formatted in EROFS.
Left: DiskInfo on Z Fold 4
Right: DiskInfo on S23
(Screenshot credits: Chris Wedel)
I don't have an S23 or Z Fold 4 for comparison, but if you do, you can check out the partitions yourself using the DiskInfo app or by using the Linux 'mount' command.
EROFS is a performant and space efficient file system for read-only partitions developed by Huawei that has gained popularity among other Android OEMs like Xiaomi and OPPO. It has been supported in Linux since 5.4.
In fact, Google once planned to make it mandatory for Android 13 launch devices to use EROFS for their read-only partitions. However, they relaxed this requirement and now only require kernel support to pass VTS/VSR-13.
Google was going to use EROFS for its own Pixel 7 series as well, but they reverted this decision quite late in the development cycle when they discovered a regression in app launch times for some apps like Google Photos.
If you want to learn more about EROFS, check out Google's talk at LPC 2022, or read my blog post on it.
Thanks to HN user chenxiaolong for first bringing this change to my attention. They examined the firmware of the European S23 Ultra and found that all dynamic partitions under 'super' (system, system_ext, product, vendor, odm) were formatted in EROFS.
๐15
Mishaal's Android News Feed
Lol, you can change the carrier name to anything you want using this same API. Screenshots: @nullby
@nullby has released an app that you can use to change the carrier name to whatever you want. Have fun!
X (formerly Twitter)
kamila ๐ธ๐ณ๏ธโโง๏ธ (@Za_Raczke) on X
Release: Carrier Vanity Name 1.0 - visually change the carrier name on your Android device - ROOTLESSLY!
๐19๐ฅ7โค5
Itโs that time of the year again: Google has announced Android 14 Developer Preview 1 ๐ฑ! As always, the official announcement is aimed at developers and is light on details about the sheer breadth of changes that are in the release. You can check out Googleโs blog post to see whatโs new, or read my summary over on Twitter.
Twitter
Itโs that time of the year again: Google has announced Android 14 Developer Preview 1 ๐ฑ! As always, the official announcement is aimed at developers and is light on details about the sheer breadth of changes that are in the release. Hereโs my summary of whatโฆ
๐ฅ42๐5๐คฉ2
As always, Iโll be digging through the latest Android release to find whatโs new. Googleโs blog post on Android 14 DP1 makes it sound like there arenโt changes (to be fair, itโs aimed at developers), but as always, there are a LOT of new features and changes. Since this digging is a very involved process, and for my own sanity, if you want to see whatโs new in Android 14 DP1, check out my constantly updated thread on Twitter for all the details!
๐30๐ฅ6๐ฅฐ1
Here is a list of articles I published today on major new features I found in Android 14:
- Android 14โs predictive back gesture lets you preview where youโre going when you swipe back
- Android 14 will let you restrict what photos apps can access even if they donโt use the Photo Picker
- Android 14 could let you clone apps so you can use two accounts at the same time
- Android 14 has built-in support for Google and Samsungโs Health Connect platform
- Android 14 makes root certificates updatable via Google Play to protect users from malicious CAs
- Android 14 could make it easier to find and delete carrier-installed bloatware
- Android 14โs advanced memory protection feature can protect your device from memory safety bugs
- Android 14โs predictive back gesture lets you preview where youโre going when you swipe back
- Android 14 will let you restrict what photos apps can access even if they donโt use the Photo Picker
- Android 14 could let you clone apps so you can use two accounts at the same time
- Android 14 has built-in support for Google and Samsungโs Health Connect platform
- Android 14 makes root certificates updatable via Google Play to protect users from malicious CAs
- Android 14 could make it easier to find and delete carrier-installed bloatware
- Android 14โs advanced memory protection feature can protect your device from memory safety bugs
โค38๐14๐ฅ7
Heya, here are some more articles I recently published about Android 14. Check them out!
- Android 14 may bring better support for keyboards with touchpad gestures and modifier key remapping
- Android 14โs regional preferences feature could tell apps to use your preferred calendar and number system
- Android 14 adds new features to make third-party app stores work even better
- Android 14 may bring better support for keyboards with touchpad gestures and modifier key remapping
- Android 14โs regional preferences feature could tell apps to use your preferred calendar and number system
- Android 14 adds new features to make third-party app stores work even better
๐28๐ฅ9โค1๐1
The first Beta for the Privacy Sandbox on Android begins rolling out today to eligible devices.
"Eligible" devices likely means devices running Android 13 with extension SDK level 4 or later or devices on Android 14 DP1. It's an A/B test, though, so you may not get it.
You'll see a notification if your device has been selected to participate in the Beta.
"Eligible" devices likely means devices running Android 13 with extension SDK level 4 or later or devices on Android 14 DP1. It's an A/B test, though, so you may not get it.
You'll see a notification if your device has been selected to participate in the Beta.
๐23โค4
Google Play's data safety section might be integrated directly into Android 14. The permission dialog as well as Settings now supports showing data safety information, starting with location.
More screenshots/full details at xda-developers.com.
More screenshots/full details at xda-developers.com.
๐33โค12
This media is not supported in your browser
VIEW IN TELEGRAM
Interesting: Google is introducing Partial Custom Tabs, so apps can open links in a tab that only takes up part of the screen. You can customize the tab height in pixels. This works with a handful of browsers, including Chrome, with additional support coming soon.
Apparently this has been supported since Chrome 107 and version 1.5.0-alpha01 of androidx.browser. Stable version 1.5.0 of androidx.browser was just released a few days ago, though.
Apparently this has been supported since Chrome 107 and version 1.5.0-alpha01 of androidx.browser. Stable version 1.5.0 of androidx.browser was just released a few days ago, though.
๐26๐ฅ12๐ค2
Google says it is working with its ecosystem partners to harden the security of firmware (software that runs on processors excluding the AP, like the baseband), as they are a critical part of the attack surface of Android devices.
In particular, they are exploring and enabling compiler-based sanitizers (BoundSan, IntSan) and other exploit mitigations (CFI, kCFI, Shadow Call Stack, Stack Canaries) as well as enabling further memory safety features in firmware.
Because bare metal targets are severely resource-constrained compared to the AP, Google is choosing to harden the most exposed attack surface while minimizing any performance/stability impact.
In addition, Google has also scaled its fuzzing activities to allow fuzzers to run in perpetuity (continuous fuzzing), in the hopes of finding and patching more bugs in firmware.
Google continues to accept reports from third-party contributors. With the launch of Android 13, Google updated its Vulnerability Rewards Program to "further highlight remotely exploitable bugs in connectivity firmware."
More details in Google's blog post.
In particular, they are exploring and enabling compiler-based sanitizers (BoundSan, IntSan) and other exploit mitigations (CFI, kCFI, Shadow Call Stack, Stack Canaries) as well as enabling further memory safety features in firmware.
Because bare metal targets are severely resource-constrained compared to the AP, Google is choosing to harden the most exposed attack surface while minimizing any performance/stability impact.
In addition, Google has also scaled its fuzzing activities to allow fuzzers to run in perpetuity (continuous fuzzing), in the hopes of finding and patching more bugs in firmware.
Google continues to accept reports from third-party contributors. With the launch of Android 13, Google updated its Vulnerability Rewards Program to "further highlight remotely exploitable bugs in connectivity firmware."
More details in Google's blog post.
Google Online Security Blog
Hardening Firmware Across the Android Ecosystem
Posted by Roger Piqueras Jover, Ivan Lozano, Sudhi Herle, and Stephan Somogyi, Android Team A modern Android powered smartphone is a comp...
๐25๐7โค4
Google Play Protect is now using a new "Protected Download" API to verify the integrity of models and heuristics downloaded onto devices, ensuring malware authors haven't tampered with them. Protected Download "enables downloading of resources to the device with support for a binary transparency log based verification", ensuring that the resources are officially from Google.
Protected Download is a new API offered by "Private Compute Services", the open source app that Android System Intelligence (part of Android's "Private Compute Core") uses to retrieve model updates from external servers. "The mechanism of download is open-sourced to show that through the connection to the server personal user data is not sent to Google, but rather receiving the model or heuristics in an encrypted and verified manner."
I haven't seen a public announcement of this yet, but it was released last week.
Protected Download is a new API offered by "Private Compute Services", the open source app that Android System Intelligence (part of Android's "Private Compute Core") uses to retrieve model updates from external servers. "The mechanism of download is open-sourced to show that through the connection to the server personal user data is not sent to Google, but rather receiving the model or heuristics in an encrypted and verified manner."
I haven't seen a public announcement of this yet, but it was released last week.
GitHub
release Protected Download ยท google/private-compute-services@1f7cf2c
PiperOrigin-RevId: 509476510
๐11๐2
Google paid out >$12m in bounties for >2900 issues submitted through their Vulnerability Reward Program (VRP) in 2022.
The Android VRP paid out ~$4.8m in rewards, including the highest payout in Google VRP history at $605k. The Android Chipset Security Reward Program (ACSRP), an invite-only reward program offered by Google in collaboration with SoC vendors, rewarded $486k in 2022 for >700 reports.
Google has expanded the scope of its VRP to include more Google devices, incentivizing research into "the latest versions of Google Nest and Fitbit".
More details on Google's VRP in 2022 can be found in this blog post.
The Android VRP paid out ~$4.8m in rewards, including the highest payout in Google VRP history at $605k. The Android Chipset Security Reward Program (ACSRP), an invite-only reward program offered by Google in collaboration with SoC vendors, rewarded $486k in 2022 for >700 reports.
Google has expanded the scope of its VRP to include more Google devices, incentivizing research into "the latest versions of Google Nest and Fitbit".
More details on Google's VRP in 2022 can be found in this blog post.
๐20๐5