Why did Google remove native per-app internet blocking from stock Android?
One of the most frustrating regressions in modern Android is the loss of basic system-level control over app internet access.
In older Android builds and on certain OEM skins (like MIUI on my Redmi Note 10), blocking an app from accessing the network was effortless: open app settings, toggle off Wi-Fi and Mobile Data, and you're done. It was ideal for privacy, stopping invasive ads in offline games, and preventing background bandwidth hogging.
Now, on modern stock Android and newer Android tablets (like my POCO Tab), that native toggle is gone or stripped down to just limiting "background data." If you connect to Wi-Fi, every single app on your device gets internet access unless you run a third-party local VPN firewall that often doesn't even work, which in itself is a clunky workaround for a feature that used to be built-in.
Why would Google strip away basic user control over network permissions? Has anyone found a clean way around this without running a persistent VPN service?
TLDR: Older Android builds and custom skins (like MIUI) let you block any app from accessing Wi-Fi or Mobile Data with a simple toggle. Modern Android stripped native Wi-Fi blocking, forcing reliance on clunky third-party firewalls. Why remove basic user network control, and are there any clean workarounds?
Edit: Sp
https://redd.it/1xamxge
@reddit_android
One of the most frustrating regressions in modern Android is the loss of basic system-level control over app internet access.
In older Android builds and on certain OEM skins (like MIUI on my Redmi Note 10), blocking an app from accessing the network was effortless: open app settings, toggle off Wi-Fi and Mobile Data, and you're done. It was ideal for privacy, stopping invasive ads in offline games, and preventing background bandwidth hogging.
Now, on modern stock Android and newer Android tablets (like my POCO Tab), that native toggle is gone or stripped down to just limiting "background data." If you connect to Wi-Fi, every single app on your device gets internet access unless you run a third-party local VPN firewall that often doesn't even work, which in itself is a clunky workaround for a feature that used to be built-in.
Why would Google strip away basic user control over network permissions? Has anyone found a clean way around this without running a persistent VPN service?
TLDR: Older Android builds and custom skins (like MIUI) let you block any app from accessing Wi-Fi or Mobile Data with a simple toggle. Modern Android stripped native Wi-Fi blocking, forcing reliance on clunky third-party firewalls. Why remove basic user network control, and are there any clean workarounds?
Edit: Sp
https://redd.it/1xamxge
@reddit_android
Reddit
From the Android community on Reddit
Explore this post and more from the Android community
Here’s Your First Look at the Galaxy S27 Ultra and S27 Pro Batteries
https://sammyguru.com/galaxy-s27-ultra-pro-batteries-first-look/
https://redd.it/1xdlr4r
@reddit_android
https://sammyguru.com/galaxy-s27-ultra-pro-batteries-first-look/
https://redd.it/1xdlr4r
@reddit_android
SammyGuru
Here’s Your First Look at the Galaxy S27 Ultra and S27 Pro Batteries
Galaxy S27 Ultra and S27 Pro batteries appear in certification listings, hinting at bigger capacities and a long-awaited battery upgrade.
Samsung Boosts Exynos M2700 Modem Efficiency for Galaxy S27
https://hi-tech.ua/en/samsung-boosts-exynos-modem-efficiency-for-galaxy-s27/
https://redd.it/1xdlsqw
@reddit_android
https://hi-tech.ua/en/samsung-boosts-exynos-modem-efficiency-for-galaxy-s27/
https://redd.it/1xdlsqw
@reddit_android
hi-Tech.ua
Samsung Boosts Exynos Modem Efficiency for Galaxy S27
Samsung has addressed power consumption issues in its Exynos chips. The new M2700 modem for the Galaxy S27 series promises significant efficiency gains.
Galaxy S27 phones with Exynos modems said to be more power efficient
https://www.sammobile.com/news/galaxy-s27-plus-exynos-m2700-modem-more-power-efficient/
https://redd.it/1xejtbj
@reddit_android
https://www.sammobile.com/news/galaxy-s27-plus-exynos-m2700-modem-more-power-efficient/
https://redd.it/1xejtbj
@reddit_android
SamMobile
Galaxy S27 phones with Exynos modems said to be more power efficient - SamMobile
While Samsung's Exynos chips have become a lot faster and more power-efficient over the years, they still haven't matched their MediaTek and Snapdragon counterp
Samsung Exynos 2700 reportedly beats flagship Snapdragon 8 Elite Extreme Gen 6 by up to 20% in new tests
https://www.notebookcheck.net/Samsung-Exynos-2700-reportedly-beats-flagship-Snapdragon-by-up-to-20-in-new-tests.1433421.0.html
https://redd.it/1xf4s2y
@reddit_android
https://www.notebookcheck.net/Samsung-Exynos-2700-reportedly-beats-flagship-Snapdragon-by-up-to-20-in-new-tests.1433421.0.html
https://redd.it/1xf4s2y
@reddit_android
Notebookcheck
Samsung Exynos 2700 reportedly beats flagship Snapdragon by up to 20% in new tests
Samsung's upcoming Exynos 2700 has reportedly outperformed Qualcomm's Snapdragon 8 Elite Extreme Gen 6 by approximately 20% in internal CPU and GPU benchmarks. The alleged results also suggest a substantial advantage over the standard Snapdragon 8 Elite Gen…
CRT Screen-Off Animation v1.2.1 - Classic mode & Fixes.
https://github.com/Typongtv/CRT-Screen-Off-Animation/releases/tag/v1.2.1
https://redd.it/1xf8ke8
@reddit_android
https://github.com/Typongtv/CRT-Screen-Off-Animation/releases/tag/v1.2.1
https://redd.it/1xf8ke8
@reddit_android
GitHub
Release CRT Screen-Off Animation v1.2.1 · Typongtv/CRT-Screen-Off-Animation
🚀 What's Fixed in v1.2.1
Fixed Animation Skipping with "Reduce Animations" / 0x Animation Scale:
If you had "Reduce Animations" enabled in Accessibility settings or set a...
Fixed Animation Skipping with "Reduce Animations" / 0x Animation Scale:
If you had "Reduce Animations" enabled in Accessibility settings or set a...
I built a pedometer that draws today's steps as one straight line on a map
Most step apps give you a number, and most walking apps record a GPS track of where you actually went. I wanted something in between. Stepline takes the steps you already walk in a normal day and draws them as a single straight line from your front door, along a heading you pick in the morning. 8,000 steps at your stride length is just a distance, and the app shows the town that distance would reach as the crow flies.
It uses the phone's step counter, not a constant GPS fix, so it barely touches the battery and it doesn't record where you actually walked. You set a home point once. After that the only moving part is the line. If you don't pick a heading, an evening notification tells you how far north, east, south and west would have got you, and you can open a compass and look at the other directions yourself.
The part I ended up caring about is keeping the line going. You can point it at a city and let it run for weeks, or follow a real long route: Route 66, the Camino Francés, the Tokaido, Land's End to John o' Groats, and a few more. The route is the actual road, with the towns in order, and your daily steps move you along it. There's also a plain logbook of past days and a lifetime total measured against the circumference of the earth, which is mostly there because I wanted to see how far a year of ordinary walking really is.
Health Connect is optional. If you use it, steps from a watch come in too, and the phone sensor fills the gaps while the watch app is behind on syncing. No account. Step data stays on the phone. Android only.
The daily line is free. Longer journeys, the full logbook and a couple of map styles are a one-time purchase, no subscription.
Happy to answer questions about the step counting, Health Connect, or why the line is straight.
https://play.google.com/store/apps/details?id=com.polyhistor.stepline
https://redd.it/1xf6sfj
@reddit_android
Most step apps give you a number, and most walking apps record a GPS track of where you actually went. I wanted something in between. Stepline takes the steps you already walk in a normal day and draws them as a single straight line from your front door, along a heading you pick in the morning. 8,000 steps at your stride length is just a distance, and the app shows the town that distance would reach as the crow flies.
It uses the phone's step counter, not a constant GPS fix, so it barely touches the battery and it doesn't record where you actually walked. You set a home point once. After that the only moving part is the line. If you don't pick a heading, an evening notification tells you how far north, east, south and west would have got you, and you can open a compass and look at the other directions yourself.
The part I ended up caring about is keeping the line going. You can point it at a city and let it run for weeks, or follow a real long route: Route 66, the Camino Francés, the Tokaido, Land's End to John o' Groats, and a few more. The route is the actual road, with the towns in order, and your daily steps move you along it. There's also a plain logbook of past days and a lifetime total measured against the circumference of the earth, which is mostly there because I wanted to see how far a year of ordinary walking really is.
Health Connect is optional. If you use it, steps from a watch come in too, and the phone sensor fills the gaps while the watch app is behind on syncing. No account. Step data stays on the phone. Android only.
The daily line is free. Longer journeys, the full logbook and a couple of map styles are a one-time purchase, no subscription.
Happy to answer questions about the step counting, Health Connect, or why the line is straight.
https://play.google.com/store/apps/details?id=com.polyhistor.stepline
https://redd.it/1xf6sfj
@reddit_android
Google Play
Stepline: Pedometer & Walk Map - Apps on Google Play
Step counter that maps your walk as the crow flies. Virtual walks & real routes.
What security vulnerabilities do full Android security updates fix that Google Play system updates and Google Play services cannot?
I want to discuss a practical problem with Android's security update policy, particularly for people who buy budget and mid-range phones.
Smartphones have become increasingly expensive, and not everyone can afford to replace a perfectly functional phone every few years. For many people, a mid-range phone is already a substantial purchase, and keeping it for four, five, or even more years is a matter of affordability rather than preference, especially in today's climate where phone prices are skyrocketing. For example I purchased a Redmi Note 13 Pro 5G in August of 2024 for around ₹23,000 which rounds off to about $274 at the time. This year the latest model in the same line of phones i.e the Redmi Note 17 Pro 5G costs ₹40,000 ($421) for identical RAM and storage configurations. The prices have basically doubled in a matter of 2 years.
However, manufacturers often provide security updates for a limited period. Once that support ends, users are effectively left with a choice between continuing to use a functional device with an increasingly outdated security patch level or spending money on a replacement they might not otherwise need.
As I understand it, Google can independently update certain Android components through Google Play system updates (Project Mainline), while Google Play services can also receive updates without requiring a full OTA update from the phone manufacturer.
This raises a few questions for me:
1. What exactly does a full Android security update patch that Google Play system updates and Google Play services updates cannot?
2. If Google can independently patch many Android components, why are regular manufacturer-provided security updates still necessary? Is the main difference the Linux kernel, hardware drivers, vendor-specific code, bootloader, and firmware?
3. If a phone has the latest Google Play services and Google Play system update but an outdated Android security patch level, how much protection does it actually have against newer vulnerabilities?
4. Can Google Play updates mitigate or completely fix certain vulnerabilities on an otherwise outdated Android device, or do they only cover a relatively limited subset of Android's security issues?
5. How secure is a phone if the user is mindful about how they use it? i.e Regularly updating all their apps via the Play Store, making sure they aren't downloading any APKs from shady websites or connecting to public Wi-Fi etc.
I'm not suggesting that Google Play updates can replace full security updates. I'm trying to understand precisely where their capabilities overlap and where the limitations are.
https://redd.it/1xf4jo6
@reddit_android
I want to discuss a practical problem with Android's security update policy, particularly for people who buy budget and mid-range phones.
Smartphones have become increasingly expensive, and not everyone can afford to replace a perfectly functional phone every few years. For many people, a mid-range phone is already a substantial purchase, and keeping it for four, five, or even more years is a matter of affordability rather than preference, especially in today's climate where phone prices are skyrocketing. For example I purchased a Redmi Note 13 Pro 5G in August of 2024 for around ₹23,000 which rounds off to about $274 at the time. This year the latest model in the same line of phones i.e the Redmi Note 17 Pro 5G costs ₹40,000 ($421) for identical RAM and storage configurations. The prices have basically doubled in a matter of 2 years.
However, manufacturers often provide security updates for a limited period. Once that support ends, users are effectively left with a choice between continuing to use a functional device with an increasingly outdated security patch level or spending money on a replacement they might not otherwise need.
As I understand it, Google can independently update certain Android components through Google Play system updates (Project Mainline), while Google Play services can also receive updates without requiring a full OTA update from the phone manufacturer.
This raises a few questions for me:
1. What exactly does a full Android security update patch that Google Play system updates and Google Play services updates cannot?
2. If Google can independently patch many Android components, why are regular manufacturer-provided security updates still necessary? Is the main difference the Linux kernel, hardware drivers, vendor-specific code, bootloader, and firmware?
3. If a phone has the latest Google Play services and Google Play system update but an outdated Android security patch level, how much protection does it actually have against newer vulnerabilities?
4. Can Google Play updates mitigate or completely fix certain vulnerabilities on an otherwise outdated Android device, or do they only cover a relatively limited subset of Android's security issues?
5. How secure is a phone if the user is mindful about how they use it? i.e Regularly updating all their apps via the Play Store, making sure they aren't downloading any APKs from shady websites or connecting to public Wi-Fi etc.
I'm not suggesting that Google Play updates can replace full security updates. I'm trying to understand precisely where their capabilities overlap and where the limitations are.
https://redd.it/1xf4jo6
@reddit_android
Reddit
From the Android community on Reddit
Explore this post and more from the Android community
How smooth is Android-to-Android restoration & Google Messages pairing for seasonal device swapping?
Hi everyone,
I live in Turkey and bought my Pixel 10 Pro XL in Spain. Local laws block unregistered foreign phones after 8 months per calendar year (4 months SIM + 4 months eSIM). Registration costs over $1,200, which isn't worth it.
Once my 8 months are up, I have two main routes:
Route 1: Rotating between two devices (Use Pixel for 8 months, store it in a drawer, and switch to a backup phone for 4 months until the SIM timer resets on Jan 1st):
A. Alternate with a second Pixel, a can buy a new one, still cheaper than registration fee.
B. Alternate with another Android brand same idea on A but with different brand)
Route 2: Carrying two phones
C. Keep my SIM in the Mi 11T Pro (for calls & personal hotspot) and tether the Pixel over Wi-Fi 24/7.
Questions:
How seamless is restoring data between Pixels or other Android devices on a regular basis? Does backup/restore actually pick up right where you left off?
If you daily-drive a 2-phone hotspot setup, how annoying is it in practice (battery drain, connectivity lag)?
How is the experience using Google Messages (Web/Device Pairing) over Wi-Fi to handle SMS on the Pixel while the SIM stays in the secondary phone? Is it reliable for 2FA codes and daily texts?
Which approach would you choose?
https://redd.it/1xf1sto
@reddit_android
Hi everyone,
I live in Turkey and bought my Pixel 10 Pro XL in Spain. Local laws block unregistered foreign phones after 8 months per calendar year (4 months SIM + 4 months eSIM). Registration costs over $1,200, which isn't worth it.
Once my 8 months are up, I have two main routes:
Route 1: Rotating between two devices (Use Pixel for 8 months, store it in a drawer, and switch to a backup phone for 4 months until the SIM timer resets on Jan 1st):
A. Alternate with a second Pixel, a can buy a new one, still cheaper than registration fee.
B. Alternate with another Android brand same idea on A but with different brand)
Route 2: Carrying two phones
C. Keep my SIM in the Mi 11T Pro (for calls & personal hotspot) and tether the Pixel over Wi-Fi 24/7.
Questions:
How seamless is restoring data between Pixels or other Android devices on a regular basis? Does backup/restore actually pick up right where you left off?
If you daily-drive a 2-phone hotspot setup, how annoying is it in practice (battery drain, connectivity lag)?
How is the experience using Google Messages (Web/Device Pairing) over Wi-Fi to handle SMS on the Pixel while the SIM stays in the secondary phone? Is it reliable for 2FA codes and daily texts?
Which approach would you choose?
https://redd.it/1xf1sto
@reddit_android
Reddit
From the Android community on Reddit
Explore this post and more from the Android community
Do you charge your phone overnight or try to top it up during the day?
I keep hearing conflicting advice about whether overnight charging is bad for the battery. Curious what most people actually do and whether you've noticed any difference after a year or two.
https://redd.it/1xf38cm
@reddit_android
I keep hearing conflicting advice about whether overnight charging is bad for the battery. Curious what most people actually do and whether you've noticed any difference after a year or two.
https://redd.it/1xf38cm
@reddit_android
Reddit
From the Android community on Reddit
Explore this post and more from the Android community
ShizuCallRecorder v2.0.0 - Native Audio Rework, VoIP + third-party app support.
# Hey! v2.0.0 is out👀.
I have been working on this update for over 2 months.
Available on Github: https://github.com/kitsumed/ShizuCallRecorder
F-Droid and IzzyOnDroid releases will follow in the next weeks.
This release includes a few bug fixes, but the main change is a FULL REFACTORING of the audio capture logic. The scrcpy-server binary is gone. We now handle audio capture natively with code in our own app. This gives us direct control over PCM audio which this release already makes some use of, and may in the future make even more.
I also want to announce that we now support VoIP / IN_COMMUNICATION type of audio capture starting Android 14. (So most third-party apps like WhatsApp, Signal, Meta/Facebook apps and carriers using VoIP or Wi-Fi Calling!).
I know I said at multiple places online that it would be starting Android 13, but hum, how do I say this.. Oops, the shell has one permission missing in that version that SPECIFICALLY prevents IN_COMMUNICATION capture and I tested everything except specifically capturing that... 😅
I also want to thank everyone who decided to sponsor me via GitHub Sponsors. ❤️ I'm still amazed I even managed to get 4 monthly sponsors, let alone occasional one-time sponsors.
I will remind you again, but if you use this project often, please consider supporting me. If you do not wish to do it via money, you can still contribute. For example, this new v2.0.0 release is missing translations. You can help on Weblate.
Last minute edit: While updating packages, I was forced to support Android 17. So, Android 17 R1 builds are now supported, updated some reflection stuff. That said, if your Shizuku versions does not work with Android 17, then report the issue to your Shizuku repository, not me. Versions of the v1.x.x release should also work on Android 17, except if you have specific devices that need workaround that uses reflection, in thoses case, only v2.0.0 will work since I have added the specific code for the new version.
# What's the future of the project?
v2.0.0 is what I wanted v1.x.x to be. A audio native call recording application. This was my original goal when I first started the project, but at the time, I did not know Android development well, never used Kotlin, Android Studio, read parts of AOSP source code, nor did I know about reflection. My solution was to use the scrcpy-server binary, and little by little, I started learning more and I somehow pulled it off over the last 2 months.
In that regard, I partially see ShizuCallRecorder's current position as feature complete / partially in a bug-fix lifecycle. The app is working well for almost all users. There are still more features I wish to add. For example, \#3, which would also cause a rework of how the UI works. Then, that UI rework may cause another plan of mine, \#97 (adding support to connect to ADB ourselves without Shizuku).
I have increasingly wanted to do this because I am not satisfied with the practices of most "updated/popular" Shizuku forks. Their unsafe security and release practices, along with heavy AI/LLM agent usage without a lot of human interaction. We can also add to that their tendencies of mixing tons of other forks features into their own using an LLM, which makes questionable implementations and default configurations.
I am also interested in this because it would allow me to enforce a safer way of making the app work and give me direct control over more failure points. It does, however, worry me, as Shizuku in itself is a complex app, mainly due to the complexity of supporting different manufacturers (OEMs).
For the time being, I continue to recommend thedjchi Shizuku fork, as they offered good security options inside
# Hey! v2.0.0 is out👀.
I have been working on this update for over 2 months.
Available on Github: https://github.com/kitsumed/ShizuCallRecorder
F-Droid and IzzyOnDroid releases will follow in the next weeks.
This release includes a few bug fixes, but the main change is a FULL REFACTORING of the audio capture logic. The scrcpy-server binary is gone. We now handle audio capture natively with code in our own app. This gives us direct control over PCM audio which this release already makes some use of, and may in the future make even more.
I also want to announce that we now support VoIP / IN_COMMUNICATION type of audio capture starting Android 14. (So most third-party apps like WhatsApp, Signal, Meta/Facebook apps and carriers using VoIP or Wi-Fi Calling!).
I know I said at multiple places online that it would be starting Android 13, but hum, how do I say this.. Oops, the shell has one permission missing in that version that SPECIFICALLY prevents IN_COMMUNICATION capture and I tested everything except specifically capturing that... 😅
I also want to thank everyone who decided to sponsor me via GitHub Sponsors. ❤️ I'm still amazed I even managed to get 4 monthly sponsors, let alone occasional one-time sponsors.
I will remind you again, but if you use this project often, please consider supporting me. If you do not wish to do it via money, you can still contribute. For example, this new v2.0.0 release is missing translations. You can help on Weblate.
Last minute edit: While updating packages, I was forced to support Android 17. So, Android 17 R1 builds are now supported, updated some reflection stuff. That said, if your Shizuku versions does not work with Android 17, then report the issue to your Shizuku repository, not me. Versions of the v1.x.x release should also work on Android 17, except if you have specific devices that need workaround that uses reflection, in thoses case, only v2.0.0 will work since I have added the specific code for the new version.
# What's the future of the project?
v2.0.0 is what I wanted v1.x.x to be. A audio native call recording application. This was my original goal when I first started the project, but at the time, I did not know Android development well, never used Kotlin, Android Studio, read parts of AOSP source code, nor did I know about reflection. My solution was to use the scrcpy-server binary, and little by little, I started learning more and I somehow pulled it off over the last 2 months.
In that regard, I partially see ShizuCallRecorder's current position as feature complete / partially in a bug-fix lifecycle. The app is working well for almost all users. There are still more features I wish to add. For example, \#3, which would also cause a rework of how the UI works. Then, that UI rework may cause another plan of mine, \#97 (adding support to connect to ADB ourselves without Shizuku).
I have increasingly wanted to do this because I am not satisfied with the practices of most "updated/popular" Shizuku forks. Their unsafe security and release practices, along with heavy AI/LLM agent usage without a lot of human interaction. We can also add to that their tendencies of mixing tons of other forks features into their own using an LLM, which makes questionable implementations and default configurations.
I am also interested in this because it would allow me to enforce a safer way of making the app work and give me direct control over more failure points. It does, however, worry me, as Shizuku in itself is a complex app, mainly due to the complexity of supporting different manufacturers (OEMs).
For the time being, I continue to recommend thedjchi Shizuku fork, as they offered good security options inside
GitHub
GitHub - kitsumed/ShizuCallRecorder: ShizuCallRecorder empowers ADB through Shizuku to record phone calls on non-rooted device!
ShizuCallRecorder empowers ADB through Shizuku to record phone calls on non-rooted device! - kitsumed/ShizuCallRecorder
ShizuCallRecorder v2.0.0 - Native Audio Rework, VoIP + third-party app support.
# Hey! v2.0.0 is out👀.
I have been working on this update for over 2 months.
**Available on Github**: [https://github.com/kitsumed/ShizuCallRecorder](https://github.com/kitsumed/ShizuCallRecorder)
F-Droid and IzzyOnDroid releases will follow in the next weeks.
This release includes a few bug fixes, but the main change is a **FULL REFACTORING** of the audio capture logic. The scrcpy-server binary is gone. We now handle audio capture natively with code in our own app. This gives us direct control over PCM audio which this release already makes some use of, and may in the future make even more.
I also want to announce that **we now support VoIP / IN\_COMMUNICATION type of audio capture starting Android 14**. (So **most third-party apps like WhatsApp, Signal, Meta/Facebook apps and carriers using VoIP or Wi-Fi Calling**!).
I know I said at multiple places online that it would be starting Android 13, but hum, how do I say this.. Oops, the shell has one permission missing in that version that SPECIFICALLY prevents IN\_COMMUNICATION capture and I tested everything except specifically capturing that... 😅
I also want to thank everyone who decided to sponsor me via [GitHub Sponsors](https://github.com/sponsors/kitsumed). ❤️ I'm still amazed I even managed to get 4 monthly sponsors, let alone occasional one-time sponsors.
I will remind you again, but if you use this project often, please consider supporting me. If you do not wish to do it via money, you can still contribute. For example, **this new v2.0.0 release is missing translations**. You can help on [Weblate](https://hosted.weblate.org/engage/shizucallrecorder/).
**Last minute edit**: While updating packages, I was forced to support Android 17. So, **Android 17 R1 builds are now supported**, updated some reflection stuff. That said, if your Shizuku versions does not work with Android 17, then report the issue to your Shizuku repository, not me. Versions of the v1.x.x release should also work on Android 17, except if you have specific devices that need workaround that uses reflection, in thoses case, only v2.0.0 will work since I have added the specific code for the new version.
# What's the future of the project?
v2.0.0 is what I wanted v1.x.x to be. A audio native call recording application. This was my original goal when I first started the project, but at the time, I did not know Android development well, never used Kotlin, Android Studio, read parts of AOSP source code, nor did I know about reflection. My solution was to use the scrcpy-server binary, and little by little, I started learning more and I somehow pulled it off over the last 2 months.
In that regard, I partially see ShizuCallRecorder's current position as feature complete / partially in a bug-fix lifecycle. The app is working well for almost all users. **There are still more features I wish to add**. For example, [\#3](https://github.com/kitsumed/ShizuCallRecorder/issues/3), which would also cause a rework of how the UI works. Then, that UI rework may cause another plan of mine, [\#97](https://github.com/kitsumed/ShizuCallRecorder/issues/97) (adding support to connect to ADB ourselves without Shizuku).
I have increasingly wanted to do this because I am not satisfied with the practices of most "updated/popular" Shizuku forks. Their unsafe security and release practices, along with heavy AI/LLM agent usage without a lot of human interaction. We can also add to that their tendencies of mixing tons of other forks features into their own using an LLM, which makes questionable implementations and default configurations.
I am also interested in this because it would allow me to enforce a safer way of making the app work and give me direct control over more failure points. It does, however, worry me, as Shizuku in itself is a complex app, mainly due to the complexity of supporting different manufacturers (OEMs).
For the time being, I continue to recommend thedjchi Shizuku fork, as they offered good security options inside
# Hey! v2.0.0 is out👀.
I have been working on this update for over 2 months.
**Available on Github**: [https://github.com/kitsumed/ShizuCallRecorder](https://github.com/kitsumed/ShizuCallRecorder)
F-Droid and IzzyOnDroid releases will follow in the next weeks.
This release includes a few bug fixes, but the main change is a **FULL REFACTORING** of the audio capture logic. The scrcpy-server binary is gone. We now handle audio capture natively with code in our own app. This gives us direct control over PCM audio which this release already makes some use of, and may in the future make even more.
I also want to announce that **we now support VoIP / IN\_COMMUNICATION type of audio capture starting Android 14**. (So **most third-party apps like WhatsApp, Signal, Meta/Facebook apps and carriers using VoIP or Wi-Fi Calling**!).
I know I said at multiple places online that it would be starting Android 13, but hum, how do I say this.. Oops, the shell has one permission missing in that version that SPECIFICALLY prevents IN\_COMMUNICATION capture and I tested everything except specifically capturing that... 😅
I also want to thank everyone who decided to sponsor me via [GitHub Sponsors](https://github.com/sponsors/kitsumed). ❤️ I'm still amazed I even managed to get 4 monthly sponsors, let alone occasional one-time sponsors.
I will remind you again, but if you use this project often, please consider supporting me. If you do not wish to do it via money, you can still contribute. For example, **this new v2.0.0 release is missing translations**. You can help on [Weblate](https://hosted.weblate.org/engage/shizucallrecorder/).
**Last minute edit**: While updating packages, I was forced to support Android 17. So, **Android 17 R1 builds are now supported**, updated some reflection stuff. That said, if your Shizuku versions does not work with Android 17, then report the issue to your Shizuku repository, not me. Versions of the v1.x.x release should also work on Android 17, except if you have specific devices that need workaround that uses reflection, in thoses case, only v2.0.0 will work since I have added the specific code for the new version.
# What's the future of the project?
v2.0.0 is what I wanted v1.x.x to be. A audio native call recording application. This was my original goal when I first started the project, but at the time, I did not know Android development well, never used Kotlin, Android Studio, read parts of AOSP source code, nor did I know about reflection. My solution was to use the scrcpy-server binary, and little by little, I started learning more and I somehow pulled it off over the last 2 months.
In that regard, I partially see ShizuCallRecorder's current position as feature complete / partially in a bug-fix lifecycle. The app is working well for almost all users. **There are still more features I wish to add**. For example, [\#3](https://github.com/kitsumed/ShizuCallRecorder/issues/3), which would also cause a rework of how the UI works. Then, that UI rework may cause another plan of mine, [\#97](https://github.com/kitsumed/ShizuCallRecorder/issues/97) (adding support to connect to ADB ourselves without Shizuku).
I have increasingly wanted to do this because I am not satisfied with the practices of most "updated/popular" Shizuku forks. Their unsafe security and release practices, along with heavy AI/LLM agent usage without a lot of human interaction. We can also add to that their tendencies of mixing tons of other forks features into their own using an LLM, which makes questionable implementations and default configurations.
I am also interested in this because it would allow me to enforce a safer way of making the app work and give me direct control over more failure points. It does, however, worry me, as Shizuku in itself is a complex app, mainly due to the complexity of supporting different manufacturers (OEMs).
For the time being, I continue to recommend thedjchi Shizuku fork, as they offered good security options inside
GitHub
GitHub - kitsumed/ShizuCallRecorder: ShizuCallRecorder empowers ADB through Shizuku to record phone calls on non-rooted device!
ShizuCallRecorder empowers ADB through Shizuku to record phone calls on non-rooted device! - kitsumed/ShizuCallRecorder
the app, were very open and receptive to security-related requests, and ensured their release CI/process was using the best security they could once notified about it. Sadly, they are currently no longer maintaining the fork, but it is still working as of writing this. I have yet to find another fork which makes me feel comfortable using it, let alone recommend it.
The next new feature you may soon see is a new call detection method based on notifications [\#131](https://github.com/kitsumed/ShizuCallRecorder/issues/131), because while we can now start recording third-party apps on Android 14+, not all apps use Android Telecom, which is currently the only way we can detect calls. Notification-based detection could be a workaround for a low number of users / weird apps. Please note, however, that I do not wish to implement advanced support for all kinds of third-party apps, I want my support to be best-effort focused and as generic as possible to prevent maintenance burdens as soon as an X third-party app makes an update.
# Tldr On Changes
* Native audio handling. The big big audio rework branch.
* Fixed a bug causing unexpected folder creation when contact name contains forward slash (/)
* **VoIP / third-party apps recording is now possible starting Android 14+**
* **You can split uplink/downlink to different channel in audio a single audio file.**
* New capture method for users who had capture issues when the phone was on speaker mode.
* **New audio codecs**, xHE-AAC, HE-AAC v2, AMR WB and more along with **more bitrate option**.
* Fixed a regression that in specific scenario caused the app to add \`+\` to a short phone number.
Reddit Only Info:
This time both this reddit post and the Github release body will be similar in what they say compared to the original release post I did a couple of month ago as I took a good 40+ minutes writing this. Feel free to share your feedback and tell me if the app works! Hopefully everything does not break down.
I don't intent to make new post here unless there are other big news or changes in the future, but I feel like this one was important. Some stuff may also break, please look for existing issue if that is the case.
I also had some fun on paintDotnet and made a new banner for the Github page! We're almost at 2K stars.
I would also invite you to read [Android May Soon Restrict On-Device ADB](https://kitsumed.github.io/blog/posts/android-may-soon-restrict-on-device-adb/) if you have free time as this may affect the future of this project **beyond my own and others users abilities**.
https://redd.it/1xekauh
@reddit_android
The next new feature you may soon see is a new call detection method based on notifications [\#131](https://github.com/kitsumed/ShizuCallRecorder/issues/131), because while we can now start recording third-party apps on Android 14+, not all apps use Android Telecom, which is currently the only way we can detect calls. Notification-based detection could be a workaround for a low number of users / weird apps. Please note, however, that I do not wish to implement advanced support for all kinds of third-party apps, I want my support to be best-effort focused and as generic as possible to prevent maintenance burdens as soon as an X third-party app makes an update.
# Tldr On Changes
* Native audio handling. The big big audio rework branch.
* Fixed a bug causing unexpected folder creation when contact name contains forward slash (/)
* **VoIP / third-party apps recording is now possible starting Android 14+**
* **You can split uplink/downlink to different channel in audio a single audio file.**
* New capture method for users who had capture issues when the phone was on speaker mode.
* **New audio codecs**, xHE-AAC, HE-AAC v2, AMR WB and more along with **more bitrate option**.
* Fixed a regression that in specific scenario caused the app to add \`+\` to a short phone number.
Reddit Only Info:
This time both this reddit post and the Github release body will be similar in what they say compared to the original release post I did a couple of month ago as I took a good 40+ minutes writing this. Feel free to share your feedback and tell me if the app works! Hopefully everything does not break down.
I don't intent to make new post here unless there are other big news or changes in the future, but I feel like this one was important. Some stuff may also break, please look for existing issue if that is the case.
I also had some fun on paintDotnet and made a new banner for the Github page! We're almost at 2K stars.
I would also invite you to read [Android May Soon Restrict On-Device ADB](https://kitsumed.github.io/blog/posts/android-may-soon-restrict-on-device-adb/) if you have free time as this may affect the future of this project **beyond my own and others users abilities**.
https://redd.it/1xekauh
@reddit_android
GitHub
[Feature]: Add the NotificationListener call detection method. · Issue #131 · kitsumed/ShizuCallRecorder
Checklist I have searched existing issues and discussions and this is not a duplicate. I am suggesting a new feature or enhancement for ShizuCallRecorder itself, NOT for Shizuku or another app. I h...
x-post /r/Oppo Potential widespread speaker defect in Oppo Find X10 Pro Max
TL;DR: Every Oppo Find X10 Pro Max I have tested (7 units) has significant speaker resonance at around 800 Hz, causing it to buzz at certain speech frequencies (for example in Zoom)
Long version:
Recently purchased 2 white 16GB + 1TB X10 Pro Max, and those along with 3 new replacement units officially provided by Oppo had the same defect.
A strong resonance (physical buzzing) at around 800 Hz for both the top & bottom speakers. Sadly it is very obvious for certain voices when using Zoom.
Try https://www.szynalski.com/tone-generator/
Change the generator volume to max && set the phone volume to max. Sweep the frequency to around 800 Hz and you will hear the buzzing. Also present in 2 display units I tried.
So every unit I've tried (2 units purchased from official Oppo dealers, 3 official brand new replacement units, 2 display units) showed buzzing speakers.
https://redd.it/1xe9529
@reddit_android
TL;DR: Every Oppo Find X10 Pro Max I have tested (7 units) has significant speaker resonance at around 800 Hz, causing it to buzz at certain speech frequencies (for example in Zoom)
Long version:
Recently purchased 2 white 16GB + 1TB X10 Pro Max, and those along with 3 new replacement units officially provided by Oppo had the same defect.
A strong resonance (physical buzzing) at around 800 Hz for both the top & bottom speakers. Sadly it is very obvious for certain voices when using Zoom.
Try https://www.szynalski.com/tone-generator/
Change the generator volume to max && set the phone volume to max. Sweep the frequency to around 800 Hz and you will hear the buzzing. Also present in 2 display units I tried.
So every unit I've tried (2 units purchased from official Oppo dealers, 3 official brand new replacement units, 2 display units) showed buzzing speakers.
https://redd.it/1xe9529
@reddit_android
Google lied about android 17 instagram camera optimization
I'm on Android 17 and the in-app camera on instagram is as shitty as before. Still no lens switching while zooming in.
https://redd.it/1xe1do7
@reddit_android
I'm on Android 17 and the in-app camera on instagram is as shitty as before. Still no lens switching while zooming in.
https://redd.it/1xe1do7
@reddit_android
Reddit
From the Android community on Reddit
Explore this post and more from the Android community
what is the most useless pre-installed stock app that you immediately banish into a hidden folder
every brand out there forces a massive wall of bloatware and proprietary stock apps onto your home screen the second you turn on a new phone. im talking about their own clunky web browsers, terrible notes apps, native calendars, or random assistant tools that nobody asked for.
what is the absolute worst stock app on your current device that you immediately disable or hide away because you strictly use third-party alternatives?
https://redd.it/1xdrdpf
@reddit_android
every brand out there forces a massive wall of bloatware and proprietary stock apps onto your home screen the second you turn on a new phone. im talking about their own clunky web browsers, terrible notes apps, native calendars, or random assistant tools that nobody asked for.
what is the absolute worst stock app on your current device that you immediately disable or hide away because you strictly use third-party alternatives?
https://redd.it/1xdrdpf
@reddit_android
Reddit
From the Android community on Reddit
Explore this post and more from the Android community
After 19 years, iOS to Android
I just switched over to an Oppo Find X9 Ultra after being on iOS since the first iPhone! iOS' UX is better in some areas and makes every day use convenient.
1. What are some tweaks/apps you'd recommend which make using your phone more enjoyable and smooth?
2. Is there a repository somewhere I can start looking into? Where are the best resources?
I'm big on shortcuts, automation, customisation, and general productivity tweaks. Thanks so much!
https://redd.it/1xdquvv
@reddit_android
I just switched over to an Oppo Find X9 Ultra after being on iOS since the first iPhone! iOS' UX is better in some areas and makes every day use convenient.
1. What are some tweaks/apps you'd recommend which make using your phone more enjoyable and smooth?
2. Is there a repository somewhere I can start looking into? Where are the best resources?
I'm big on shortcuts, automation, customisation, and general productivity tweaks. Thanks so much!
https://redd.it/1xdquvv
@reddit_android
Reddit
From the Android community on Reddit
Explore this post and more from the Android community
Smartphones are getting closer and closer to PCs, and it's honestly incredible to watch
I’m not saying PCs are becoming useless or that smartphones will completely replace them. PCs will always have their advantages, especially for demanding workloads, professional software, upgrades, and high-end gaming.
But seriously, look at how far smartphones have come.
We went from phones with just a few megabytes of RAM to smartphones with 12 GB, 16 GB or even more. Modern mobile processors are incredibly powerful, and smartphones can now do things that would have seemed almost impossible years ago.
You can code, edit videos, multitask, run desktop-like applications, and even use your phone for tasks that once required a computer.
And one of the most exciting developments in 2026 is the growing number of unofficial native Android ports and recompilations of PC and console games. Community developers are finding ways to bring games that were never designed for Android directly to our phones, sometimes without needing traditional emulation or Windows compatibility layers.
Think about that for a moment: games originally made for PCs or consoles running directly on a smartphone.
Of course, not every port is fully native, stable, or optimized, and phones still have limitations such as cooling, battery life, and software compatibility. But the progress is genuinely impressive.
I think we're approaching a point where, for many everyday tasks and even some surprisingly demanding ones, a smartphone could be enough for a huge number of people.
I'm really curious to see where this goes over the next 5–10 years.
What do you think? Could smartphones eventually replace PCs for most people's everyday needs, or will PCs always remain essential?
https://redd.it/1xdgkul
@reddit_android
I’m not saying PCs are becoming useless or that smartphones will completely replace them. PCs will always have their advantages, especially for demanding workloads, professional software, upgrades, and high-end gaming.
But seriously, look at how far smartphones have come.
We went from phones with just a few megabytes of RAM to smartphones with 12 GB, 16 GB or even more. Modern mobile processors are incredibly powerful, and smartphones can now do things that would have seemed almost impossible years ago.
You can code, edit videos, multitask, run desktop-like applications, and even use your phone for tasks that once required a computer.
And one of the most exciting developments in 2026 is the growing number of unofficial native Android ports and recompilations of PC and console games. Community developers are finding ways to bring games that were never designed for Android directly to our phones, sometimes without needing traditional emulation or Windows compatibility layers.
Think about that for a moment: games originally made for PCs or consoles running directly on a smartphone.
Of course, not every port is fully native, stable, or optimized, and phones still have limitations such as cooling, battery life, and software compatibility. But the progress is genuinely impressive.
I think we're approaching a point where, for many everyday tasks and even some surprisingly demanding ones, a smartphone could be enough for a huge number of people.
I'm really curious to see where this goes over the next 5–10 years.
What do you think? Could smartphones eventually replace PCs for most people's everyday needs, or will PCs always remain essential?
https://redd.it/1xdgkul
@reddit_android
Reddit
From the Android community on Reddit
Explore this post and more from the Android community
Is there a reason android isn't getting decompiled with AI?
With all of the news about how things are getting decompiled by AI I'm curious if there exist any practical reasons why the proprietary drivers behind Android are not a target (or if it would be useful at all). It seems like the goal of LibrePhone was to do this work:
>While there is significant work in mobile freedom, most phones remain nonfree due to a wide range of proprietary firmware blobs, even in otherwise free operating systems. LibrePhone is the FSF project aimed at freeing these blobs. - LibrePhone home page
I wouldn't be surprised if there solid reasons this is significantly harder or even not that useful. I'm sure it's a lot harder than doing it for a video game but I'm not sure if it will even be useful, or legal to use.
https://redd.it/1xdkrz3
@reddit_android
With all of the news about how things are getting decompiled by AI I'm curious if there exist any practical reasons why the proprietary drivers behind Android are not a target (or if it would be useful at all). It seems like the goal of LibrePhone was to do this work:
>While there is significant work in mobile freedom, most phones remain nonfree due to a wide range of proprietary firmware blobs, even in otherwise free operating systems. LibrePhone is the FSF project aimed at freeing these blobs. - LibrePhone home page
I wouldn't be surprised if there solid reasons this is significantly harder or even not that useful. I'm sure it's a lot harder than doing it for a video game but I'm not sure if it will even be useful, or legal to use.
https://redd.it/1xdkrz3
@reddit_android
Reddit
From the NoStupidQuestions community on Reddit
Explore this post and more from the NoStupidQuestions community
Snapdragons and overheating
For a while now, snapdragon top tier chips have had a big problem with thermals. The elite chips run too hot and pull too much power. Vendors are creating custom cooling solutions to combat the high heat output.
Now we have a 5ghz chip that would be most efficient at 3.4ghz without the power draw penalty
https://redd.it/1xe8g2m
@reddit_android
For a while now, snapdragon top tier chips have had a big problem with thermals. The elite chips run too hot and pull too much power. Vendors are creating custom cooling solutions to combat the high heat output.
Now we have a 5ghz chip that would be most efficient at 3.4ghz without the power draw penalty
https://redd.it/1xe8g2m
@reddit_android
Reddit
From the Android community on Reddit
Explore this post and more from the Android community