Eynnzerr/TelemetryCleaner

Overview

Some Chinese-market Android firmware ships carrier device-management components such as SystemHelper and RegService. They have no launcher entry, run scheduled background collection, and cannot be disabled or removed through normal settings. TelemetryCleaner is a Kotlin Android app that detects these packages, shows their installation state and permissions per user space, and lets you uninstall or restore them.

The README cites traffic measurements from a WiSec 2023 paper that observed carrier components reporting data on some Chinese samples WiSec 2023 paper, and includes an analysis of SystemHelper's permissions and behavior on an OPPO device SystemHelper analysis. The project is framed as a learning tool for understanding Android package management, while acknowledging that carriers have legitimate reasons to collect operational data in some scenarios.

How it works

The app talks directly to the system package manager over Binder, proxied by Shizuku running as the shell user. This bypasses ROMs that block the pm command-line entry point while still letting the system enforce its own permission and package-state checks Binder implementation. If a ROM rejects uninstalling a system app at the command layer, the app retries through a hidden IPackageManager.deletePackageAsUser call via app_process, and only shows success after re-reading package state; the original system error is preserved if the fallback also fails app_process fallback.

Automatic cleaning is off by default. When enabled, it checks the selected user space on a configured interval and only acts on components on the auto-clean list.

Quick start

Requirements: Android 10 or later and a working Shizuku installation.

1. Start Shizuku following the official setup guide, via ADB or wireless debugging (wireless debugging requires Android 11+).
2. Install the app from GitHub Releases and grant it Shizuku authorization.
3. Choose the user space to inspect and run detection.
4. Open a component's details to review its declared permissions, or select components for batch uninstall.
5. To undo, restore the component using the system-retained APK.

Uninstalling acts on the selected space and deletes that space's component data, so review the details before confirming.

Built-in component list and verification

The catalogue covers carrier packages across several vendors: a cross-vendor Unicom package, OPPO/OnePlus/realme, Xiaomi/Redmi/POCO, vivo, Huawei and old Honor, Honor, Meizu/Flyme, and first-generation Redmi/Red Magic (Nubia). The README marks which entries the author or community members have actually verified. SystemHelper and the OPPO components were verified by the author; Xiaomi and Huawei by community members; Honor, Meizu and Nubia entries are unverified; vivo's com.vivo.devicereg is not supported on some models, with freezing offered as a fallback.

Constraints

• Root is not required, but Shizuku must be running and authorized.
• Uninstalling system components can break device features. The README reports that uninstalling vivo Device Management caused call-recording failure on at least one device.
• Components outside the built-in list are not covered; per-app details and restore behavior depend on the ROM keeping the original APK.
• No license is declared in the repository metadata.
• Only some vendors have been tested; the author asks users to report model, system version, package name and result in Issues.

HotRepo's take

The project entered HotRepo's new-project list on 2026-11-13, gaining 17 stars in roughly three hours and ending that window at 117 stars and 7 forks. That is a single short snapshot, not a trend. What stands out technically is the two-path uninstall design: a Binder call through Shizuku plus an app_process fallback for ROMs that reject the first path, with the original error surfaced rather than masked. The component table's explicit verification status makes it clear where the risk of untested uninstalls lies.