Saturday APPreciation thread (Aug 08 2026) - Your weekly app recommendation/request thread!

Note 1. You can search for previous [weekly Saturday threads\](https://www.reddit.com/r/Android/search/?q=Saturday+APPreciation+thread&type=posts&sort=new)

Note 2. You can also search for previous [daily threads\](https://www.reddit.com/r/Android/search/?q=daily+superthread&include\_over\_18=on&restrict\_sr=on&t=all&sort=new).

Note 3. Join our IRC and Telegram chat-rooms! Please see our wiki for instructions.

This weekly Saturday thread is for:
* App promotion,
* App praise/sharing

If you are a developer, you may promote your own app ONLY under the bolded, distinguished moderator comment. Users: if you think someone is trying to bypass this rule by promoting their app in the general thread, click the report button so we can take a look!

https://redd.it/1viu7ak
@reddit_android

Samsung Galaxy Z Flip8 Review: The Flip Rolls On - MrMobile
https://www.youtube.com/watch?v=HoVsWE1_JUk

https://redd.it/1vj47gv
@reddit_android

The Old Guard vs. The Luxury Powerhouse: Xperia 1 VIII vs. Honor Magic 6 RSR Camera Shootout - LL Techview
https://www.youtube.com/watch?v=aw7h8SWCWdQ

https://redd.it/1vjg1ut
@reddit_android

Daily Superthread (Aug 09 2026) - Your daily thread for questions, device recommendations and general discussions!

Note 1. You can search for previous daily threads.

Note 2. Join our IRC and Telegram chat-rooms! Please see our wiki for instructions.

Please post your questions here. Feel free to use this thread for general questions/discussion as well.

https://redd.it/1vjo3t6
@reddit_android

Sunday Rant/Rage (Aug 09 2026) - Your weekly complaint thread!

Note 1. You can search for previous weekly Sunday threads

Note 2. Join our IRC and Telegram chat-rooms! Please see our wiki for instructions.

This weekly Sunday thread is for you to let off some steam and speak out about whatever complaint you might have about:

Your device.

Your carrier.

Your device's manufacturer.

An app

Any other company



Rules

1) Please do not target any individuals or try to name/shame any individual. If you hate Google/Samsung/OnePlus etc. for one thing that is fine, but do not be rude to an individual app developer.

2) If you have a suggestion to solve another user's issue, please leave a comment but be sure it's constructive! We do not want any flame-wars.

3) Be respectful of other's opinions. Even if you feel that somebody is "wrong" you don't have to go out of your way to prove them wrong. Disagree politely, and move on.

https://redd.it/1vjo3ti
@reddit_android

Everybody's binning: MediaTek and Qualcomm both quietly cut GPU cores for cheaper flagships
https://www.notebookcheck.net/Everybody-s-binning-MediaTek-and-Qualcomm-both-quietly-cut-GPU-cores-for-cheaper-flagships.1363949.0.html

https://redd.it/1vk36vu
@reddit_android

What if Android let you install desktop apps through the Play Store?

# What if Android let you install desktop apps through the Play Store?

Disclaimer & Sourcing: This post presents a purely hypothetical user experience concept. The visual assets, button frames, and store templates were smashed together from Play Store screenshots and public Android UI layout references found via Google Images. All template elements belong to their respective copyright owners. These graphics have been modified solely for non-commercial, illustrative purposes to map out a feature concept. I am not affiliated with Google or Android.

Every year phones get more powerful, and every year desktop modes get a little better. Yet, for some incredibly strange reason, the moment I plug my phone into a monitor, I am still mostly running mobile software stretched across a 27-inch screen. It's less “my phone became a computer” and more “my phone app has been enlarged against its will.”

Am I hating on other Android modes? Possibly. Am I an Android systems engineer? Absolutely not, but since when has that ever stopped anybody?

The fact remains that putting many mobile apps on a desktop-sized display exposes layouts and limitations that they were never designed for. And though desktop Linux applications can already be made to run on Android, the current routes often involve developer settings, terminal commands, unfamiliar package managers, or third-party environments. That is perfectly acceptable for enthusiasts who are familiar with Linux tooling and approximately nobody else.

In other words, normal people are largely limited to mobile interfaces, mobile browser behaviour, and whichever desktop-sized layouts individual developers decided they wanted to support.

So, in my extensive qualifications as Someone Who Finds This Annoying (TM), I propose Android SkyView: a consumer-facing Android feature that makes desktop Linux applications installable and manageable through the Google Play Store.

\[View Play Store Mockup\](https://i.imgur.com/pptZDGe.png/img)

Did I make that name up? Yes, but trust me, there were worse options on the table.

Mobile, as shown in the image, would install the standard Android application. Desktop would install the SkyView-compatible desktop build. Hybrid would install both and choose the appropriate experience based on the screen and input setup.

But that's the visible product. The less glamorous question is what Android would need underneath it.

# What Happens Under the Hood

Because Android already uses the Linux kernel and now includes virtualisation infrastructure through AVF, Google has much of the low-level foundation needed to build a managed desktop Linux environment. The missing piece is a consumer-facing application and distribution model.

It would use one Android-managed Linux environment built on AVF rather than packaging an entire guest operating system for every application, because good lord, storage cannot handle that. Desktop applications could then be sandboxed within that shared guest while reusing its common libraries and base system, although Google would need to define the packaging, permissions, and isolation model.

Conceptually, that would include a lightweight Linux guest managed by Android, shared GTK/Qt and system libraries, and individual Play Store apps installed as comparatively thin layers above them.

And because of compatibility issues:

SkyView would prioritise native ARM64 Linux builds, potentially distributed through a Google-defined package format or adapted from existing formats such as Flatpak.
SkyView could optionally provide x86-to-ARM binary translation for legacy applications. Because translation would add performance and power overhead, Android could limit demanding translated workloads to validated devices or recommend docked, powered operation. Native ARM64 builds would remain the goal, though. I don't think anybody wants their battery gone in an hour.

# Battery, Thermals, and Storage

Battery life is very important too, and since desktop software is

What if Android let you install desktop apps through the Play Store?

# What if Android let you install desktop apps through the Play Store?

***Disclaimer & Sourcing:*** *This post presents a purely hypothetical user experience concept. The visual assets, button frames, and store templates were smashed together from Play Store screenshots and public Android UI layout references found via Google Images. All template elements belong to their respective copyright owners. These graphics have been modified solely for non-commercial, illustrative purposes to map out a feature concept. I am not affiliated with Google or Android.*

Every year phones get more powerful, and every year desktop modes get a little better. Yet, for some incredibly strange reason, the moment I plug my phone into a monitor, I am still mostly running mobile software stretched across a 27-inch screen. It's less “my phone became a computer” and more “my phone app has been enlarged against its will.”

Am I hating on other Android modes? Possibly. Am I an Android systems engineer? Absolutely not, but since when has that ever stopped anybody?

The fact remains that putting many mobile apps on a desktop-sized display exposes layouts and limitations that they were never designed for. And though desktop Linux applications can already be made to run on Android, the current routes often involve developer settings, terminal commands, unfamiliar package managers, or third-party environments. That is perfectly acceptable for enthusiasts who are familiar with Linux tooling and approximately nobody else.

In other words, normal people are largely limited to mobile interfaces, mobile browser behaviour, and whichever desktop-sized layouts individual developers decided they wanted to support.

So, in my extensive qualifications as Someone Who Finds This Annoying (TM), I propose **Android SkyView**: a consumer-facing Android feature that makes desktop Linux applications installable and manageable through the Google Play Store.

[\[View Play Store Mockup\]](https://i.imgur.com/pptZDGe.png[/img])

Did I make that name up? Yes, but trust me, there were worse options on the table.

Mobile, as shown in the image, would install the standard Android application. Desktop would install the SkyView-compatible desktop build. Hybrid would install both and choose the appropriate experience based on the screen and input setup.

But that's the visible product. The less glamorous question is what Android would need underneath it.

# What Happens Under the Hood

Because Android already uses the Linux kernel and now includes virtualisation infrastructure through AVF, Google has much of the low-level foundation needed to build a managed desktop Linux environment. The missing piece is a consumer-facing application and distribution model.

It would use one Android-managed Linux environment built on AVF rather than packaging an entire guest operating system for every application, because good lord, storage cannot handle that. Desktop applications could then be sandboxed within that shared guest while reusing its common libraries and base system, although Google would need to define the packaging, permissions, and isolation model.

Conceptually, that would include a lightweight Linux guest managed by Android, shared GTK/Qt and system libraries, and individual Play Store apps installed as comparatively thin layers above them.

And because of compatibility issues:

* SkyView would prioritise native ARM64 Linux builds, potentially distributed through a Google-defined package format or adapted from existing formats such as Flatpak.
* SkyView could optionally provide x86-to-ARM binary translation for legacy applications. Because translation would add performance and power overhead, Android could limit demanding translated workloads to validated devices or recommend docked, powered operation. Native ARM64 builds would remain the goal, though. I don't think anybody wants their battery gone in an hour.

# Battery, Thermals, and Storage

Battery life is very important too, and since desktop software is

heavy as it is, SkyView would introduce a sort of intelligent state hibernation. When docked or connected to power, SkyView could allow supported apps greater CPU, memory, and GPU access within Android’s thermal and resource limits. When undocked, inactive Linux environments could be suspended or hibernated to reduce background usage so the battery isn't eviscerated into nothingness.

[\[View hibernation and background reduction\]](https://i.imgur.com/B1PZdFX.png[/img])

Storage permissions would also be a headache since Android loves sandboxing and Linux loves an open file system. Google would need a secure file-broker layer that exposes user-approved Android folders to SkyView applications through the Storage Access Framework or a successor API. Otherwise, users would download a PDF in the desktop browser and spend the next hour questioning where it went, much as I question life at three in the morning.

# User Experience

The biggest thing about all of this is that it would be basically seamless. Users should barely need to know that Linux is doing its own thing under the hood. That, frankly, is how it should be.

Desktop packages would still need to be published, signed, updated, and supported by their developers or trusted distributors, however. Google Play would apply compatibility checks, permission declarations, security scanning, and update management just as it does for Android apps. SkyView should not quietly scrape random Linux repositories and hope nobody uploads a virus wearing a LibreOffice moustache.

The Play Store would also recognise whether the device supports SkyView based on device eligibility and provide installation options accordingly.

[\[View SkyView inaccessible mockup\]](https://i.imgur.com/kZ7DMJ6.png[/img])

[\[View SkyView accessible mockup\]](https://i.imgur.com/VgjKc3W.png[/img])

In Hybrid mode (both APK and Linux), Android could provide shared file access, account handoff, and synchronisation APIs. Apps that support a shared profile could switch cleanly between their Android and desktop versions, while unsupported apps would retain separate settings.

**Illustrative Hardware Tiers** (Google and manufacturers would determine eligibility using performance validation):

* For devices that do not meet Google’s validated performance and virtualisation requirements, the consumer SkyView feature would remain unavailable.
* For mid-range devices, it would be a somewhat limited standard environment running basically one or at most a few desktop apps at the same time.
* For flagship/higher-end devices, SkyView would, if hardware supports it, present the full, unfettered version with the multi-window desktop and most heavy workstation apps available.

(Again, this is illustrative. Some devices have 6GB of RAM and could handle all of SkyView wonderfully, and devices like tablets shouldn't need to be docked for access to this feature. Google and manufacturers can determine what their devices support themselves.)

Additionally, Linux apps designed for touch could also run while undocked on supported devices. Lower-level experimental tooling could remain available in development builds, but unsupported consumer devices would not receive SkyView through the Play Store.

SkyView could apply Material You styling to Android-managed window chrome and offer optional GTK/Qt integration packages for applications that support them. In touchscreen mode, the system could enlarge its own title bars, taskbar controls, window handles, and launcher elements, while developers could opt into a touch-friendly desktop profile inside their applications. The platform should style what it owns and leave application interfaces alone. No app should break because Android wanted one of its buttons to be a different colour.

Desktop Linux applications commonly target Wayland or X11-based environments, while Android uses its own graphics and window-management stack. SkyView would therefore need a low-latency display, input, clipboard, audio, and window-integration layer so applications feel native rather than like a remote

desktop session running at twelve frames per second.

And that is Android SkyView! It's not supposed to be a replacement for Windows workstations or gaming PCs, but a way to make desktop apps more accessible without requiring their owners to become part-time Linux administrators. Ain't nobody got time for that.

A lot of the baseline is already there--the missing step is turning that capability into something ordinary people can use without requiring users to understand virtualisation, package managers, or terminal commands.

But would you use this? More importantly, which part would collapse first under real-world engineering constraints?

https://redd.it/1vk2acn
@reddit_android

The only eink device running Android 17?

The Musnap Neo 2 ships with Android 14 userspace, but its hardware boundary is an Android 12-era GKI 5.10.233 kernel with vendor policy level 31. It is also rootable out of the box and that made it an interesting AOSP target: instead of touching stock partitions, I keep the stock kernel/vendor stack and boot replacement generic-arm64 /system images as temporary DSUs.

The hardware is a 6-inch 1448×1072 e‑ink panel. Its display path is not exposed through a generic Android display interface, so the project captures physical-display composition from SurfaceFlinger, converts it into the panel’s evidenced 16-level grayscale input domain, and submits an owned buffer through the device-specific vendor e‑ink engine.

That proprietary lower layer still handles panel conversion, waveform selection, and panel transport. It is the reason this is an integration project rather than “flash a GSI and call it done.”

Across the tested AOSP branches: Android 14, Android 15, Android 16, and Android 17 / API 37, the same presentation path has worked: SurfaceFlinger composition reaches the vendor e‑ink engine, Android UI is visible and usable on the physical panel, and repeated refreshes are accepted without recorded lower-engine rejections in the tested diagnostics.

The frontlight path is also working at a narrow, testable level: calibrated cool-only and warm-only midpoint requests, plus explicit zero/off, completed without Android-side write failure. There is persistence and sleep/wake replay now, and lift cover to wake works, but I haven't integrated it with the native brightness control yet instead I have a simple controller apk with some config settings right now.

I can’t distribute a flashable image because it needs proprietary libraries, waveform resources, and calibration data though. The AOSP-side code and build logic are publishable; the device-specific runtime pieces have to come from the owner’s own stock firmware. Not sure if there is interest in the presentation-adapter itself as these eink panels are ubiquitous across the industry.

E: https://github.com/eink-fan/eink-aosp-lab

https://preview.redd.it/7c7mh13ehdih1.jpg?width=960&format=pjpg&auto=webp&s=75ab18befd0eb43f96a7dcd0dbd6a3621cf9e413

https://redd.it/1vjtmtc
@reddit_android

Got Root on my S22 Ultra! Ported CVE-2026-43499 exploit (Android 15)

Hey everyone,

I just published a port of the CVE-2026-43499 exploit for the Samsung Galaxy S22 Ultra (codename: `b0q` / SM-S908W). The exploit successfully establishes an arbitrary read/write primitive, switches SELinux to permissive, and spawns a root helper daemon, giving you full root access.

**Status:** This vulnerability is **currently UNPATCHED** by Samsung and works on the absolute latest firmware available!

🔗 **Repo Link:** https://github.com/sarabpal-dev/IonStack-S22U

**Currently Supported Target:**

* **Device:** Samsung Galaxy S22 Ultra (SM-S908W)

* **Android:** 15 / SDK 35

* **Firmware:** `AP3A.240905.015.A2.S908WVLS8FYG7`

* **Kernel:** 5.10.226-android12-9-30958166-abS908WVLS8FYG7

* **Architecture:** aarch64

\### ⚠️ Reliability & Kernel Panic Warning

Because the exploit relies on a race condition and precise timing, it can be somewhat unreliable and may trigger a kernel panic on bad runs.

**Tips for success:** For the highest success rate, **reboot your device** before running it to ensure a clean heap state. Close all background apps, keep the screen unlocked, and do not touch the phone while the exploit is running so background tasks don't disturb the timing.

\### 🛠️ Porting to other firmwares / Generating `target.h`

The offsets in the repo are specific to the firmware version listed above. If you are on a different build, you need to generate your own `target.h` file by extracting kernel symbols and offsets from your specific kernel binary.

Here is how to do it:

1. **Extract the uncompressed kernel binary (`Image`)** from your device's `boot.img`.

2. Follow the step-by-step instructions in the `target_generator` directory to install dependencies, compile the `kallsyms` extractor, and run the generator script.

👉 **[Full step-by-step instructions for the target generator can be found here\](https://github.com/sarabpal-dev/IonStack-S22U/blob/main/target_generator/README.md)**

Once you generate your `target.h`, place it in `src/targets/<YOUR_FIRMWARE_VERSION>/target.h` and compile using `make PROJECT=<YOUR_FIRMWARE_VERSION>`.

\### 🚀 How to Deploy and Run

Once compiled, push the binaries to your device:

```bash

adb push build/S908WVLS8FYG7/bin/cve-2026-43499 /data/local/tmp/cve-2026-43499

adb push build/S908WVLS8FYG7/bin/cve-2026-43499-root /data/local/tmp/cve-2026-43499-root

adb push build/S908WVLS8FYG7/bin/cve-exp32 /data/local/tmp/cve-exp32

adb shell chmod 755 /data/local/tmp/cve-2026-43499 /data/local/tmp/cve-2026-43499-root /data/local/tmp/cve-exp32

```

Execute the exploit stage to start the root daemon (it will automatically retry up to 16 times if it fails):

```bash

adb shell "LD_PRELOAD=/data/local/tmp/cve-2026-43499 sh"

```

Once successful, pop an interactive root shell:

```bash

adb shell "/data/local/tmp/cve-2026-43499-root"

```

\### 🤝 Contributions & Pull Requests

I'd love to make this exploit more stable. If you have ideas to improve reliability, optimize the futex choreography, **Pull Requests are highly appreciated and welcome!**

Check out the repo for the full source code, build instructions, and technical details on the porting changes from the v6.6 kernel to the v5.10 kernel. Technically it should work on all firmware and all varients of s22 family need to put just target.h. Please dont ask for port to other devices its impossible without having real device on hand other devices can check Root-My-Galaxy repo

https://redd.it/1vjndfi
@reddit_android

NL Tech - Don't make this $2,100 mistake! Galaxy Z Fold8 Ultra review!
https://www.youtube.com/watch?v=r97jqMkPG6s

https://redd.it/1vkau9z
@reddit_android

Daily Superthread (Aug 10 2026) - Your daily thread for questions, device recommendations and general discussions!

Note 1. You can search for previous daily threads.

Note 2. Join our IRC and Telegram chat-rooms! Please see our wiki for instructions.

Please post your questions here. Feel free to use this thread for general questions/discussion as well.

https://redd.it/1vkivsk
@reddit_android

Google Pixel 11 Pro XL Geekbench 7 result offers early look at Tensor G6 performance - Notebookcheck News
https://www.notebookcheck.net/Google-Pixel-11-Pro-XL-Geekbench-7-result-offers-early-look-at-Tensor-G6-performance.1364515.0.html

https://redd.it/1vkmz4e
@reddit_android

Google Play Store starts distributing third-party Android app stores – here’s how it works [Gallery]
https://9to5google.com/2026/08/10/google-play-store-third-party-android-app-stores-launch/

https://redd.it/1vksty7
@reddit_android

Samsung Galaxy Z Fold 8 Ultra Review: What Happens When Samsung Stops Playing It Safe
https://www.androidheadlines.com/samsung-galaxy-z-fold-8-ultra-review

https://redd.it/1vkyijv
@reddit_android

Exclusive: First images show Fairphone 6+ in Cobalt Blue
https://www.newmobile.com/Fairphone-Gen-6-Plus

https://redd.it/1vl0iob
@reddit_android

Another YouTube auto-play bug/feature (not sure which)
https://www.androidauthority.com/youtube-autoplay-bug-or-feature-3696192/

https://redd.it/1vl4lcp
@reddit_android

ANROID BEAM RETURNS!

Hey everyone,

I missed Android Beam after Google removed it, so I built a simple app that brings the same idea back.

ANRO-BEAM lets you send files between two Android phones just by holding them back to back / tapping them together.

No internet, no cloud, no account needed.

You can download it here:

https://s9723651-debug.github.io/anrobeam/

It’s still early, so I’d really appreciate any feedback or bug reports.

Thanks!

https://redd.it/1vl19ef
@reddit_android

USBIPBeta: Free, Open-Source USB/IP Server for Android (VirtualHere Alternative)

Hey everyone! 👋

If you've ever wanted to connect and share USB peripherals (like gaming steering wheels, pedals, and controllers) from an Android device to a Windows client over your local network, I built something that might help.

Introducing **USBIPBeta**—a lightweight client application and custom kernel driver suite designed to bridge Android hosts and Windows PCs using the USB/IP protocol.

# 🚀 What It Does

* **Peripheral Redirection:** Share physical USB devices attached to an Android device over your local network.
* **Sim Racing & Gaming Focus:** Great for plugging hardware like a Logitech G29 directly into an Android setup and routing it smoothly to a client machine.
* **Cross-Platform Bridge:** Consists of an Android APK host component and a Windows client executable/driver suite.

# 💻 Open Source & 100% Free

This project is completely free and open-source, and it always will be! If you want to check out the code, inspect the setup, or download the beta release, you can find everything here:

🔗 **GitHub Repository:**[https://github.com/hellfurian1228/USBIPBeta](https://github.com/hellfurian1228/USBIPBeta)

*Note: While the app is and will always remain 100% free to use, if you find it helpful and want to buy me a coffee, you can find an optional donation link over on the GitHub repo!*

https://redd.it/1vl0u2o
@reddit_android