# UAD-ng Disable vs Uninstall: Technical Differences and When to Use Each > Understand UAD-ng disable vs uninstall. Keep APKs on device or permanently remove them. Learn which UAD-ng operation suits your needs and reclaim storage. - Repository: [Universal-Debloater-Alliance/universal-android-debloater-next-generation](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation) - Tags: deep-dive - Published: 2026-06-18 --- **UAD-ng performs disable operations using `pm disable-user` to keep APKs on the device while blocking execution, whereas uninstall operations execute `pm uninstall` to permanently remove the package and reclaim storage.** The **Universal-Debloater-Alliance/universal-android-debloater-next-generation** project provides two distinct methods for removing bloatware from Android devices. Understanding the difference between disable and uninstall operations in UAD-ng helps you choose the right approach for system packages versus user-installed apps. ## What Happens Under the Hood: Disable vs Uninstall Operations When you initiate a package operation in UAD-ng, the application translates your GUI or CLI selection into specific Android Debug Bridge (ADB) commands. The fundamental distinction lies in how the Android Package Manager handles the package state. ### The Disable Operation The **disable** operation executes a command sequence that preserves the APK while rendering it inoperable. In [`crates/uad-core/src/sync.rs`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/crates/uad-core/src/sync.rs) (lines 71-88), the `apply_pkg_state_commands` function constructs the following command list when the target state is `PackageState::Disabled`: ```bash pm disable-user am force-stop pm clear ``` This sequence marks the package as disabled for the selected user profile, terminates any running processes, and wipes application data. The APK remains in the system partition, allowing you to re-enable the package later without reinstallation. ### The Uninstall Operation The **uninstall** operation triggers `pm uninstall` (or device-specific fallbacks on older Android versions) to completely remove the APK and all associated data from the device. In [`crates/uad-core/src/sync.rs`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/crates/uad-core/src/sync.rs) (lines 89-95), the same `apply_pkg_state_commands` function generates: ```bash pm uninstall ``` This command deletes the package from the system entirely, permanently freeing the storage it occupied. ## Android Version Requirements and Compatibility Not all Android versions support both operations equally. - **Disable mode** requires **Android 6.0 (Marshmallow, API 23)** or higher. On older devices, the disable checkbox appears greyed out with an "Unavailable" label in the GUI. - **Uninstall operations** work across all supported Android versions. On pre-Marshmallow devices, UAD-ng automatically falls back to legacy commands such as `pm hide` or `pm block` when `pm disable-user` is unavailable. ## Implementation in the UAD-ng Source Code The state machine logic that determines whether to disable or uninstall resides in the core Rust crates. ### State Machine Logic In [`crates/uad-core/src/uad_lists.rs`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/crates/uad-core/src/uad_lists.rs) (lines 36-44), the `PackageState` enum defines an `opposite` method. When the **disable mode** flag is enabled (`DeviceSettings.disable_mode` is `true`), the transition maps `PackageState::Enabled` to `PackageState::Disabled`. When disabled, the same transition maps to `PackageState::Uninstalled`. ### GUI Configuration The user-facing toggle appears in [`crates/uad-gui/src/views/settings.rs`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/crates/uad-gui/src/views/settings.rs) (lines 519-525). The **"Clear and disable packages instead of uninstalling them"** checkbox sets the `disable_mode` boolean. Lines 508-514 contain the descriptive text explaining that "In some cases, it can be better to **disable** a package instead of uninstalling it," particularly for OEM-protected applications. ## When to Use Disable vs Uninstall Choose your operation based on package restrictions and storage requirements. **Use Disable when:** - The package is protected by OEM security features (e.g., Samsung Knox) - You want to test removal without permanent deletion - You need the ability to restore the package quickly - The device runs Android 6.0+ but blocks uninstallation of system apps **Use Uninstall when:** - You want to permanently reclaim storage space - The package is not protected and can be removed safely - You have no intention of restoring the application - You are debloating user-installed applications rather than system packages ## Practical Examples ### Command Line Interface Disable a specific package using the CLI (requires disable mode enabled in settings): ```bash uad-ng disable com.example.bloatware ``` Uninstall a package permanently: ```bash uad-ng uninstall com.example.bloatware ``` Both commands invoke the `apply_pkg_state_commands` function in the core sync module, passing the appropriate `PackageState` variant based on your subcommand selection. ### Graphical User Interface 1. Open **Settings** in UAD-ng 2. Check **"Clear and disable packages instead of uninstalling them"** to enable disable mode 3. Select packages and apply changes 4. Uncheck the box to switch back to uninstall operations ## Summary - **Disable** uses `pm disable-user`, `am force-stop`, and `pm clear` to block execution while preserving APKs, requiring Android 6.0+. - **Uninstall** uses `pm uninstall` to permanently delete packages and free storage, working on all Android versions. - The operation mode is controlled by `DeviceSettings.disable_mode` in [`crates/uad-gui/src/views/settings.rs`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/crates/uad-gui/src/views/settings.rs) and interpreted through `PackageState::opposite` in [`crates/uad-core/src/uad_lists.rs`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/crates/uad-core/src/uad_lists.rs). - Disable is preferred for protected OEM packages; uninstall is preferred for storage reclamation. - Core command construction happens in [`crates/uad-core/src/sync.rs`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/crates/uad-core/src/sync.rs) within the `apply_pkg_state_commands` function. ## Frequently Asked Questions ### Can I re-enable a package after disabling it? Yes. Since the **disable** operation only marks the package as disabled and clears its data without removing the APK, you can re-enable it through the Android system settings or by using ADB commands. The package remains on the device in a dormant state. ### Why is the disable option greyed out on my device? The **disable** checkbox becomes unavailable on devices running Android versions below 6.0 (Marshmallow, API 23). This limitation exists because the `pm disable-user` command was introduced in API 23. Older devices lack the necessary framework support for per-user package disabling. ### Does disabling a package free up storage space? No. Disabling clears application data and cache, which may free a small amount of space temporarily, but the APK file remains in the system partition. Only **uninstall** operations permanently remove the package and reclaim the full storage amount occupied by the application. ### Which operation is safer for system packages? **Disable** is generally safer for system packages because it allows you to restore functionality if the disabled package is required by other system components. Some manufacturers protect critical packages with security features like Samsung Knox that prevent uninstallation entirely, making disable the only viable option for these applications.