Big Feedback Post

## Make Disable+Clear default instead of Uninstall
Uninstall misleads users into thinking they're clearing up space on their device, when that isn't the case.
**"Uninstalling" doesn't even uninstall app updates**, which can take up hundreds of megabytes of space, completely hidden from the user(cuz they can't see "uninstalled" apps).
And you can't even uninstall updates on "uninstalled" apps _because you can't see them_, you can only do that on Disabled apps.
There's also the "regret-factor" of users maybe wanting to re-enable some package to use it. Uninstalling them means a PC is required, while disabling lets users re-enable some packages directly from within their phone.

## Linkify text in the description ([as mentioned in #43](https://github.com/0x192/universal-android-debloater/issues/43))
Linkifying is the process of detecting links in the text and making them into proper hyperlinks.
Shouldn't be too hard to implement? Search for `http` in the description text and then linkify from that point until there's a space, `)`, `\n` or `"`.

## Make "Select all" a toggle ([as suggested in #82](https://github.com/0x192/universal-android-debloater/issues/82))
One way to program this would probably be to check if number of selected packages is >0 whenever a package is selected/unselected and change the "Select all" button to a "De-select all" if there are any selected.
The other way would be to simply swap between "Select all" and "De-select all" when they're clicked.

## Add a selection highlight
Currently there's nothing indicating which package you've selected in the list. The only highlights are when you hover and when you click, but it would be nice if there was a persistent one on the currently selected package.
Image illustrating the issue:
One of those two packages is selected, but it's impossible to see which one because there's no indication.

## Add color highlights based on removal category ([also mentioned in #82](https://github.com/0x192/universal-android-debloater/issues/82))
Recommended = Green (0,99,0 / 44,255,44)
Advanced = Blue (0,0,99 / 99,99,255)
Expert = Yellow (144,144,0 / 255,255,44)
Unsafe = Red (99,0,0 / 255,44,44)
Unlisted = Black/White? (depending on theme)
(dark-theme/light-theme color codes are the ones used in my mock-up)
The most distinguishable way to apply them would be to simply color the entire row. It would be very obvious and would additionally make it easier to distinguish between rows in general. It would probably need different colors depending on the theme to avoid low-contrast text. Both Lupin and Dark can go for the same dark colors, while Light theme would need to use brighter colors.
Here's a shitty mock-up of what it could look like:
Another way to do it would be to use some kind of outlines instead of fully filling the color, that way you might get away with the same color across all themes.

## Rework description UI and data fields
-Remove "dependencies", "neededBy"(synonymous with dependency) and "labels". I think less than 1/100 entries have data in those fields, and any such info can fit just as well in the description.
+Add a package name field and make it searchable. I've had to resort to putting package name on the first row in the description, it would be nice if there was a name field that could be displayed both in the list of packages and as a header(slightly larger text) above the description. If this name field is null/empty it should default to using the dotted package name(com.example.package) for the header. The list should always show the dotted name, and only add the package name if there is one.
+Add a "Runs in the background" field that can contain info like this (these definitions could be placed in the contribute page):
> On boot only = runs for a short time on boot, but doesn't run in the background beyond that.
> Occasionally = runs every X minutes or sporadically in the background.
> Always = always active in the background.
> Never = never runs without user input.

And of course with a null/empty field showing "Unknown" or something like that.

Crappy mock-up showing how it could look (including colors from suggestion above):
Note how the dotted package names are slightly dimmed (166,166,166) for packages that have a name, to distinguish between the text.
The selected package in the mock-up uses the JSON data shown below in the placeholder.

## Overlay theme placeholder
Roughly 90% of packages with "overlay" in their name are related to theming.
It would be nice if UAD could provide a placeholder entry for packages containing "overlay" in their dotted name that don't have any description(including packages that don't even have an entry in the JSON file).
Something like:
```json
{
"id": "overlay.package.placeholder",
"list": "Pending",
"name": "Theme-something?",
"backgroundexecution": "Never?",
"description": "Overlay packages are usually data containers for themes. They also usually have no permissions and never execute on their own, making them pointless to disable.",
"removal": "Expert"
},
```

# Info for the wiki pages
I'd gladly help updating the wiki pages if you want. (can't be done with a pull request AFAIK)
### Establish definitions for what "Removal" categories mean
Here's what I suggest:
> Recommended = Pointless or negative packages(like spyware and task-killer apps), or apps available through Google Play.
> Advanced = Breaks minor functionality, or apps that aren't easily enabled/installed through Settings/Google Play.
> Expert = Breaks widespread or potentially important functionality, but nothing important to the basic operation of Android.
> Unsafe = Can break vital parts of Android.

Packages that run in the background or contain excessive telemetry/permissions should be prioritized for Recommended over Advanced.
If there's a lack of info the package should be put in Advanced or Expert, depending on how important the package seems to be.

### Finding "Runs in background" info
Reboot, clear cached packages(Running services->Show cached processes) and see if any appear again. Packages that don't appear again only run on boot and the ones that do obviously run "occasionally".
Packages that run in the background are obviously shown in (Settings->System->Developer Options->)Running Services. BUT some packages are counted as part of the system and hidden from this menu. Some of them pop up if you have multiple users running on the device, but a more reliable method to view them is by using an app you grant the PACKAGE_USAGE_STATS permission through ADB. [Simple System Monitor](https://play.google.com/store/apps/details?id=com.dp.sysmonitor.app) is the only app I've found that shows this in Android 11.
Note that most packages that run as part of the system are unaffected by disable; they run anyway, some with reduced/no RAM usage and some with no apparent difference. I think that's dependent on whether their process lives in system- and/or user-space; system-space is unaffected by disable, while user-space system processes are blocked from running properly (removing their RAM usage). Disable/uninstall severs the connections to user-space resources, which *theoretically* could improve privacy even for the packages running in system-space, more info needed to know for sure tho.

### Figuring out what packages do (info missing from current wiki page)
The best package info/viewer app I've found is [Package Viewer](https://play.google.com/store/apps/details?id=cz.seeq.prog.android.packageviewer).
[Activity Launcher](https://f-droid.org/en/packages/de.szalkowski.activitylauncher/) is a great tool for testing what package "Activities" do (activities are listed in Package Viewer). Most of them won't run when launched manually, but some do and give useful insight into the packages.
[Android Code Search](https://cs.android.com/) is a great tool for finding info on AOSP packages if you know how to read code.

The issue describes multiple UI/UX improvements for a Rust-based Android debloating tool. Start by exploring the codebase to understand the GUI structure, likely in src/ui/. Look for package list rendering, selection logic, and description display. Each sub-feature (like linkifying text, toggling select-all, adding color highlights) will require changes across several files. Testing involves running the GUI and verifying changes match the mock-ups. The work is cross-cutting and needs familiarity with the project's architecture.

Scritto dal modello di indicizzazione a partire dal testo della issue.