Mishaal's Android News Feed
11.9K subscribers
2.2K photos
100 videos
8 files
1.94K links
Android news from an Android nerd
Download Telegram
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!
๐Ÿ‘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.
๐Ÿ‘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.
๐Ÿ‘15
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.
๐Ÿ”ฅ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
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.
๐Ÿ‘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.
๐Ÿ‘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.
๐Ÿ‘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.
๐Ÿ‘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.
๐Ÿ‘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.
๐Ÿ‘20๐Ÿ‘5