# Realme Debloater: Remove Android Bloatware Without Root Using ADB Have you ever looked at the applications installed on your Android phone and wondered why some of them are even there? Smartphone manufacturers customise Android with their own applications, services and background components. Some are useful, some are promotional, and others operate behind the scenes without much visibility to the user. Realme devices are no exception. While Android provides several ways to manage applications, removing unwanted preinstalled software is not always straightforward. Many system applications cannot simply be uninstalled through the normal Settings interface. This is where Android Debug Bridge (ADB) becomes useful. I started building [**realme-debloater**](https://github.com/Lumacodes/Realme-Debloater), a Python-based command-line utility designed to inspect installed packages and carefully manage unwanted applications on Realme devices. The idea isn't to remove as many applications as possible. It's to give users more control over what happens to their devices. **No root. No bootloader unlocking. No GUI.** ## Introducing realme-debloater [realme-debloater](https://github.com/Lumacodes/Realme-Debloater) is a command-line utility built using Python and Android Debug Bridge. It allows users to inspect installed Android packages, search for applications, review package information and manually manage removal operations. The initial device profile is based on: | Specification | Device | | --- | --- | | Device | Realme 8 5G | | Model | RMX3241 | | Android | Android 13 | | Interface | Realme UI 4.0 | | Programming language | Python | | Android communication | ADB | The tool can inspect other Android devices, but package behaviour varies depending on the model, firmware, region and Android version. It doesn't require root permissions, an unlocked bootloader, custom recovery or additional Python libraries. ## Why another Android debloating tool? There are already plenty of Android debloating scripts available on GitHub. Many focus on predefined package lists and offer options to remove multiple applications quickly. That can be convenient, but it also creates a problem: users may remove packages without understanding their purpose or dependencies. An unfamiliar package name does not automatically mean that the package is unnecessary. Some Android components support telephony, permissions, security, firmware updates and other essential functions. I wanted to approach the problem differently. Instead of automatically selecting applications for removal, realme-debloater follows a more deliberate workflow: 1. Inspect installed packages. 2. Identify the package that needs investigation. 3. Research its purpose. 4. Approve it manually. 5. Preview the proposed operation. 6. Confirm the exact package before applying removal. The approval list starts empty. There are no packages automatically marked as safe to remove. ## Features of realme-debloater The project currently focuses on practical package-management operations. - **Device diagnostics:** Check whether ADB is working and whether your phone is properly connected. - **Package inventory:** Scan installed applications and save a timestamped inventory locally. - **Package listing:** List installed packages and filter third-party applications. - **Package search:** Find packages using a search term such as `heytap`. - **Package inspection:** Inspect an individual package before deciding what to do with it. - **Manual package approval:** Add individually researched packages to a local approval list. - **Dry-run removal:** Preview a proposed removal without immediately modifying the device. - **Explicit confirmation:** Require the exact package name before applying a removal. - **Restoration records:** Record changes made through the tool and provide a command to attempt restoration. ## How to debloat a Realme phone without root The project uses ADB to communicate with the phone through USB debugging. ### Requirements You need: - Windows, macOS or Linux. - Python 3.9 or newer. - Android SDK Platform Tools (ADB). - A USB cable with data-transfer support. - USB debugging enabled on your Realme phone. ### Step 1: Connect your phone Enable Developer options and USB debugging on your Android device. Connect it to your computer and authorise the USB debugging request. Verify the connection: ```bash adb devices ``` Your device should appear with the status `device`. ### Step 2: Check the connection Open a terminal inside the project directory. Run: ```bash python3 src/realme_debloater.py doctor ``` On Windows: ```powershell py src\realme_debloater.py doctor ``` This checks the ADB connection and displays basic device information. ### Step 3: Scan installed packages Run: ```bash python3 src/realme_debloater.py scan ``` The tool creates a timestamped package inventory inside the `state` directory. This is a read-only operation. It does not remove or disable applications. ### Step 4: Search for an application For example, to find packages containing `heytap`: ```bash python3 src/realme_debloater.py search heytap ``` To inspect an individual package: ```bash python3 src/realme_debloater.py info PACKAGE.NAME ``` Replace `PACKAGE.NAME` with the exact package identifier. The inspection output is a starting point, not proof that a package is safe to remove. ## A safety-first removal workflow One of the main design decisions behind realme-debloater is separating package approval from package removal. ### 1\. Approve a package Only after researching and verifying that a package is optional should you run: ```bash python3 src/realme_debloater.py approve PACKAGE.NAME \ --reason "Verified optional" ``` The program asks you to type: ```text APPROVE ``` This adds the package to the local approval list. It does not uninstall anything. ### 2\. Preview the removal Run: ```bash python3 src/realme_debloater.py remove PACKAGE.NAME ``` The default behaviour is a dry run. The tool displays the proposed operation without changing the phone. ### 3\. Apply the removal After reviewing the operation, run: ```bash python3 src/realme_debloater.py remove PACKAGE.NAME --apply ``` The program asks you to type the exact package name again. This additional confirmation is intended to prevent accidental removal. ## What does removing an Android package actually do? The project uses Android's package-management command: ```bash pm uninstall --user 0 PACKAGE.NAME ``` The `--user 0` argument targets Android's primary user. This is an important distinction. The operation removes the application for that user, but does not erase its system image from the firmware partition. It is not equivalent to permanently deleting the system component. ### Can removed applications be restored? The project records changes in `state/changes.json`. To preview restoration: ```bash python3 src/realme_debloater.py restore PACKAGE.NAME ``` To apply restoration: ```bash python3 src/realme_debloater.py restore PACKAGE.NAME --apply ``` Restoration uses Android's: ```bash cmd package install-existing ``` This may make a preinstalled application available again for the user, but it does not necessarily recover its previous application data, preferences or updates. Restoration is useful, but it should not be mistaken for a complete backup. --- ## Case Study: Investigating CrashBox on Realme UI While examining the installed packages and background activity on my Realme device, I came across an interesting OEM component: ```text Package: com.oplus.crashbox Application: CrashBox Location: /system_ext/app/CrashBox/CrashBox.apk ``` Rather than immediately adding it to a debloating list, I decided to investigate its actual runtime behaviour using Android's diagnostic tools. This is a good example of why package names alone are not enough to determine whether an application should be removed. ### 1\. Identifying the running service I inspected the package using: ```bash adb shell dumpsys activity services com.oplus.crashbox ``` The output identified an active service: ```text com.oplus.crashbox/.CrashMonitorService ``` The package was running under UID 1000 and used the OEM-specific permission: ```text oplus.permission.OPLUS_COMPONENT_SAFE ``` The diagnostic output also identified its installation directory: ```text /system_ext/app/CrashBox/CrashBox.apk ``` This indicates that CrashBox is integrated into the system extension partition rather than being an ordinary downloaded application. ### 2\. Background activity I examined battery statistics: ```bash adb shell dumpsys batterystats --charged ``` The captured output included: | Metric | Observed value | | --- | --: | | Process CPU user time | 30 ms | | Process CPU kernel time | 40 ms | | Process starts | 20 | | CrashMonitorService starts | 4 | | Service launches | 18 | | WorkManager job execution | Approximately 1.54 seconds | | Recorded job executions | 3 | The output also contained a scheduled job associated with: ```text androidx.work.impl.background.systemjob.SystemJobService ``` ### 3\. Scheduled network-capable work I also inspected JobScheduler: ```bash adb shell dumpsys jobscheduler ``` The captured output showed periodic jobs belonging to `com.oplus.crashbox`. One of the jobs included an Internet network requirement. That is an important observation, but it needs to be interpreted carefully. A network requirement establishes that the scheduled job can run when the required network conditions are met. It does not prove that the application uploads personal information, crash reports or any particular data. ### 4\. What can we conclude? The service name `CrashMonitorService` strongly suggests a crash-monitoring or diagnostic purpose. The available evidence supports these observations: - CrashBox is installed as an OEM system component. - It has an active crash-monitoring service. - It registers scheduled background work. - At least one observed scheduled job has a network requirement. - The captured CPU usage was relatively small. However, the available ADB output does not establish exactly what information CrashBox collects, whether it transmits diagnostic reports, which servers it communicates with or how long any collected data is retained. To answer those questions, further investigation would require the exact APK manifest, application code and controlled network analysis. **My preliminary assessment:** CrashBox is an OEM diagnostic/crash-monitoring component with scheduled background activity. Its data-collection behaviour remains unverified. I would not label it spyware based on these observations, and I would not automatically classify it as safe to remove. This is precisely why I prefer inspecting packages before adding them to a debloating list. --- ## What should you avoid removing? Not everything that looks unnecessary is bloatware. Some packages are deeply integrated into Android and the manufacturer's software environment. Avoid experimenting with packages responsible for: - Android System UI and Settings. - Telephony and mobile network services. - Permission management and package installation. - Google Play services. - Device security. - OEM firmware updates and OTA functionality. - Device-specific system frameworks. The initial RMX3241 inventory includes protected update-related components such as: ```text com.oplus.ota com.oplus.sau com.oplus.sauhelper com.oplus.romupdate com.oplus.cota ``` Their presence does not mean an OTA update file is consuming storage. Package behaviour can vary between firmware versions, so a package that was removable on one Realme device should not automatically be considered safe on another. ## Does Android debloating improve privacy and performance? Debloating can reduce the number of applications available to an Android user, but the benefits depend on what is removed and how that component behaves. Removing an application does not automatically guarantee: - Better battery life. - Faster performance. - More available storage. - Complete removal of telemetry. - Protection against network tracking. `realme-debloater` is a package-management utility, not a firewall, network monitor or comprehensive Android privacy-hardening system. I would rather make a limited, verifiable claim than promise a magical performance improvement from removing a few packages. ## Project limitations The initial target is Realme 8 5G (RMX3241), Android 13 and Realme UI 4.0. Other devices can be inspected, but their package behaviour may differ. The tool also does not automatically determine whether every package is safe to remove. That decision requires research and device-specific verification. It uses user-level package uninstallation rather than permanently deleting system applications from the firmware partition. Users should back up important information before applying package changes. ## Final thoughts The Android ecosystem gives manufacturers considerable control over the software shipped with smartphones. Users should have meaningful ways to understand and manage that software too. With realme-debloater, I wanted to explore a more transparent approach to Android debloating: inspect what is installed, understand the package, preview the operation and only then decide whether to proceed. The CrashBox investigation is a small example of that philosophy. Instead of assuming that an unfamiliar OEM package is unnecessary, I examined its services, process activity and scheduled jobs. The result was a more informed assessment, not an unsupported accusation or an automatic removal recommendation. The goal isn't to remove everything. It's to understand what is running on your device and make informed decisions about it. **Inspect first. Approve manually. Remove deliberately.** ## Get the project **GitHub:** [Lumacodes/Realme-Debloater](https://github.com/Lumacodes/Realme-Debloater) Explore the source code, read the setup instructions and contribute to the project. --- ## Frequently asked questions ### Can I remove Realme bloatware without root? Yes. realme-debloater uses ADB to manage certain applications for Android's primary user. Root access and bootloader unlocking are not required. ### Does realme-debloater support Realme 8 5G? Its initial device profile targets the Realme 8 5G (RMX3241) running Android 13 and Realme UI 4.0. Other devices can be inspected, but compatibility and package behaviour are not guaranteed. ### Is ADB debloating safe? ADB debloating can be performed without root, but removing the wrong system package can still disrupt phone functionality. The project uses manual approval, dry-run previews and explicit confirmation to reduce accidental changes. ### Does `pm uninstall --user 0` delete an application permanently? No. It removes the application for the specified Android user. The application may remain in the firmware's system partition. ### Can I restore a removed Realme system app? The project provides a restoration command using Android's `cmd package install-existing`. It may restore the preinstalled application but does not necessarily recover previous app data or settings. ### What is CrashBox (`com.oplus.crashbox`)? CrashBox is an OEM system component whose observed service is named `CrashMonitorService`. ADB logs from the investigated device show scheduled background work and a network-capable job. ### Where can I download realme-debloater? The project is available on [GitHub](https://github.com/Lumacodes/Realme-Debloater).