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.

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?

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.

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 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, 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 if you have free time as this may affect the future of this project beyond my own and others users abilities.

I'm on Android 17 and the in-app camera on instagram is as shitty as before. Still no lens switching while zooming in.

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.

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?

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!

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?

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.

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