Bilibili link, Chinese only. Tldr: apple mogs, Xiaomi and mediatek great showings, Qualcomm shat the bed. I think the samsung using exynos rumors seem much more likely to be true now.

【旗舰手机芯片大横评：苹果高通发哥玄戒谁最强？-哔哩哔哩】 https://b23.tv/J4GJYI7

jfc

it feels like every single new android release comes with google removing old permissions or forcing apps to jump through extra steps just to do basic tasks. seeing that android 18 is completely blocking apps from using direct contact write permissions is just the latest example.

what is a classic open android feature or system permission that google locked down or completely ruined over the years under the excuse of privacy?

I find Airpods to be some of the best headphones even on Android, but hay that they aren't actively supported by Apple; firmware updates, custom settings, etc. You literally have to connect to an iPhone to set things up then switch back to your Android.

On the reverse side Google allows full features on iPhone for Android headphones My Pixel Buds 4 pro still get beat by Airpods Pro 3, and Don't XM5 by the Airpods Max.

Hey everyone,

​My partners and I recently launched a new community resource: https://getyahrootback.admindashboard.dev/?hl=en-AU

Our overall goal is to create a centralized, community-driven database for Android and Samsung device information, firmware mapping, and root journeys. ​We built this because we miss the early days of Android, where everything was intended to be universally available and community-focused. Our intention is to keep this website, along with all active and future projects we host, 100% free, entirely open-source, and strictly ad-free forever.

​We need your help to grow the database:

If you have data to share, please navigate to the "Send device journey tab" on our website to contribute any Samsung or general Android device info. We have a template provided there to make it easy. If you choose to contribute, we will gladly credit and thank you on the site for helping the community!

​GitHub Status:

At the bottom of it all, our data and projects tie back to our GitHub page, where all the info will be uploaded for the community to audit and use. We are currently just waiting for GitHub support to reactivate the page, but you can bookmark it here:

https://github.com/plomens

​Let us know what you think or if you have any feature requests for the site!

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.

I was tired with that little green light turning on every now and then that indicates that the camera or the microphone work. Got pissed, went to the settings, prohibited everything to spy on me (as much as a user can do via settings). Now google navigator doesn't show my speed, but that's the price I'm willing to pay.

And later on I realized that I don't see sudden fps drops when I scroll the browser anymore.

Definitely gives something to think about. Hope that helps.

Title: What makes you keep using an Android app after installing it?

Hi everyone!

I'm an independent developer working on an Android app called RyKoraL, which combines social features, fitness tracking and gaming.

I'm trying to understand what makes people keep using an app after the first installation.

In your experience, what matters most?

- Fast startup and smooth performance?

- A simple, intuitive interface?

- One standout feature?

- Friends already using the app?

- Useful updates that fix real problems?

I'm using this feedback to help guide the next improvements to my app.

If project feedback is allowed here, the Google Play listing is:

https://play.google.com/store/apps/details?id=com.rykoral.app

I'd appreciate your perspective as Android users.

Noticed this after a week of delivery apps pushing more sale pings than actual order updates, and went looking for the setting that silences one without the other. On iOS, there isn’t one.

Android requires every app to sort its notifications into named channels (what the system calls “categories”), each with its own on/off switch. Swiggy and Zomato both ship a channel literally named Promotions/Offers for this reason — you can block that one and keep delivery updates fine. iOS notification controls stop at the whole app: fully on, fully off, nothing selective unless the app itself built an in-app toggle (most don’t, or bury it).

Wrote it up with the actual Android/Apple documentation, if anyone wants the specifics: longpress.news/shopping-app-notifications-ios

Disclosure: this is my own site (I write Long Press), not a random share — flagging that upfront rather than letting it look like I stumbled on it.

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.