# How to Customize the Debloating Process in Universal Android Debloater Next Generation

> Customize Universal Android Debloater Next Generation debloating using CLI flags, editing uad_lists.json, or GUI settings to target specific apps and risk levels.

- Repository: [Universal-Debloater-Alliance/universal-android-debloater-next-generation](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation)
- Tags: how-to-guide
- Published: 2026-06-18

---

**You customize the debloating process in Universal Android Debloater Next Generation by applying filters through CLI flags, editing the [`uad_lists.json`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/uad_lists.json) package database, or configuring the GUI settings to target specific app states, risk levels, and manufacturer lists.**

Universal Android Debloater Next Generation (UAD-NG) removes unwanted system apps using a filter-driven architecture shared between its CLI and GUI components. The debloating pipeline loads package metadata from [`resources/assets/uad_lists.json`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/resources/assets/uad_lists.json), queries the device via ADB, and applies user-defined criteria through the `PackageListContext` struct. Whether you need surgical precision for a single device or automated batch processing, understanding the filtering system in `crates/uad-cli` and `crates/uad-gui` allows you to tailor the process to your specific requirements.

## Understanding the Core Architecture

The debloating workflow centers on three main components: the master package list, the filter enums, and the context that binds them together.

### The Package List and Filter System

At [`resources/assets/uad_lists.json`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/resources/assets/uad_lists.json), UAD-NG maintains a comprehensive JSON map where each key is a package name and each value contains metadata fields including `list` (AOSP, OEM, Carrier, etc.), `removal` (Recommended, Advanced, Unsafe), and a human-readable `description`. The filtering logic resides in [`crates/uad-cli/src/filters.rs`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/crates/uad-cli/src/filters.rs), which defines **`StateFilter`**, **`RemovalFilter`**, and **`ListFilter`** as enums. Each implements a `matches` method that checks a package's current `PackageState`, its removal rating, or its `UadList` classification.

### The PackageListContext Implementation

The `PackageListContext` struct in [`crates/uad-cli/src/commands.rs`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/crates/uad-cli/src/commands.rs) (lines 46-92) holds optional filter values and an optional search term. Its `filter_package` method determines whether a package survives the filtering stage. When you run a debloating command, the CLI entry point `list_packages` (lines 108-138) loads the JSON list, builds a `PackageListContext` from your flags, pulls the device state via `ACommand::list_packages_sys`, and iterates through packages using `display_package_list` to show only those matching your criteria.

## Customizing Debloating via CLI Flags

UAD-NG exposes three filter families as command-line options, allowing you to combine criteria for precise targeting.

### Filter by State and Risk

Use **`--state`** to limit results to packages that are enabled, disabled, or uninstalled:

```bash
uad list-packages --state disabled

```

Use **`--removal`** to select packages by their risk rating defined in [`uad_lists.json`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/uad_lists.json):

```bash
uad list-packages --removal recommended

```

### Filter by Source List

Restrict operations to specific manufacturer categories using **`--list`**:

```bash
uad list-packages --list oem

```

Valid list values correspond to the `UadList` enum: `Aosp`, `Carrier`, `Google`, `Misc`, `Oem`, `Pending`, and `Unlisted`.

### Combining Filters and Search

Chain multiple flags to match only packages meeting **all** criteria. Add a **`--search`** term for free-text filtering against package names and descriptions:

```bash
uad list-packages \
  --state disabled \
  --removal advanced \
  --list oem \
  --search camera

```

Omitted flags default to "All," applying no restriction for that dimension.

## Modifying the Package List

When the built-in database lacks a package or you disagree with its risk assessment, edit [`uad_lists.json`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/uad_lists.json) directly. Each entry follows this schema:

```json
"com.example.myapp": {
  "list": "Misc",
  "description": "Custom app description for my organization.",
  "dependencies": [],
  "neededBy": [],
  "labels": [],
  "removal": "Recommended"
}

```

The **`removal`** field accepts `Recommended`, `Advanced`, `Expert`, `Unsafe`, or `Unlisted`. The **`list`** field categorizes the package source. After editing, run `uad update-lists` to reload the modified JSON, or let the application fetch the latest version automatically.

## GUI-Based Customization

The graphical interface 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) mirrors the CLI filter system. Dropdown menus for State, Removal, and List update the internal `PackageListContext` and immediately refresh the package table. This approach suits users who prefer interactive point-and-click selection over terminal commands while utilizing the same underlying Rust logic.

## Programmatic Customization

For integration into larger Rust workflows, construct a `PackageListContext` manually and pass it to core functions:

```rust
use uad_cli::commands::PackageListContext;
use uad_cli::filters::{StateFilter, RemovalFilter, ListFilter};

let context = PackageListContext {
    state_filter: Some(StateFilter::Disabled),
    removal_filter: Some(RemovalFilter::Advanced),
    list_filter: Some(ListFilter::Oem),
    search: Some("camera".to_string()),
};

// Pass &context to filter_package or custom display routines

```

This pattern allows you to embed UAD-NG logic into custom automation tools while maintaining full control over the filtering criteria.

## Summary

- **Filter Architecture**: The `PackageListContext` struct in [`crates/uad-cli/src/commands.rs`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/crates/uad-cli/src/commands.rs) drives all filtering via the `filter_package` method.
- **CLI Precision**: Use `--state`, `--removal`, `--list`, and `--search` flags individually or combined to narrow target packages.
- **Data Customization**: Edit [`resources/assets/uad_lists.json`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/resources/assets/uad_lists.json) to add packages or adjust removal ratings, then reload with `uad update-lists`.
- **Interface Flexibility**: Both the CLI and GUI ([`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)) share identical filtering logic, ensuring consistent behavior across interaction modes.
- **Library Integration**: Import `uad_cli` crates to build custom `PackageListContext` instances for programmatic device management.

## Frequently Asked Questions

### Can I remove packages not listed in uad_lists.json?

Yes. While UAD-NG operates primarily from its curated [`uad_lists.json`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/uad_lists.json) database, you can add any package to this file following the standard JSON schema, or use the search functionality to locate packages by name. The application queries the device via ADB to discover all installed packages regardless of their presence in the list.

### How do I safely debloat only manufacturer-specific apps?

Use the `--list oem` filter combined with `--removal recommended` to target only OEM packages deemed safe for removal. In [`crates/uad-cli/src/filters.rs`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/crates/uad-cli/src/filters.rs), the `ListFilter::Oem` variant maps directly to the `Oem` value in the JSON database, ensuring you only see packages categorized under manufacturer-specific entries.

### What happens if I filter by multiple criteria simultaneously?

UAD-NG applies an AND logic to multiple filters. When you specify `--state disabled --removal advanced`, only packages that are **both** currently disabled on the device **and** marked as Advanced removal in [`uad_lists.json`](https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/blob/main/uad_lists.json) will appear. This intersection logic is implemented in the `matches` methods of each filter enum and evaluated by `PackageListContext::filter_package`.

### Is it possible to automate debloating across multiple devices with different settings?

Yes. Create shell scripts or Rust binaries that invoke `list_packages` or `change_package_state` with device-specific `PackageListContext` configurations. Since the CLI accepts all filters as arguments, you can script different flags for different device models or organizational policies, passing `None` for the device parameter to use the default connected ADB device.