-
Notifications
You must be signed in to change notification settings - Fork 265
FAQ
If you're confused about some jargon, or want to get more details about something (including the how, the why, etc...), we have a glossary for that
Warning
"Recommended" IS NOT ACTUALLY RECOMMENDED
This is a vestige of the previous project
UAD-ng writes logs to the user’s cache directory (see more)
-
Linux:
$XDG_CACHE_HOME/uador$HOME/.cache/uad(e.g:/home/alice/uad/) -
Windows:
Win+R=>%LOCALAPPDATA%\uad(e.g:C:\Users\alice\AppData\Local\uad) -
MacOS:
$HOME/Library/Caches/uad(e.g:/Users/alice/Library/Caches/uad/)
Tip
You can easily locate the log-file from UAD-ng by pressing the Locate the logfiles button in the "About" section.
Note
The disadvantage of logs is that they don't include crash data. If you want more information about a crash, you should run UAD-ng from a terminal
There are many reasons why this might happen.
- The Linux and Windows executables only work on 64bit x86 (AMD & Intel) CPUs. If you need to run this app on other CPUs (such as ARM), build it from source-code. If there's enough demand, we might include ARM64 executables on the "Releases" page.
- The Linux executables require GNU-libC. If you want binaries that work without
glibc, you'll need to build from source . If you use any Debian-based OS (such as Ubuntu and Linux-Mint), you already haveglibc. - Ensure the file is executable: On Windows, the anti-malware program may prevent you from running the app. On Unix (Linux and Mac), you should ensure proper permissions are set (if you followed the installation instructions correctly, don't worry about this)
-
Check the logs: if there are logs, then it's likely the GUI didn't render properly, or the window couldn't even open. This might be a problem with Iced,
wgpu, or Vulkan. You should try setting theWGPU_BACKENDenv-var toglbefore opening UADNG, which is more likely to be compatible with your hardware, as it usestiny_skiainstead of the (faster) Vulkan.
Comparison:
- UAD (legacy)
- UAD-NG has a better package-list, bug-fixes, features, cleaner code, better documented code, etc...
- The only inconvenience is that newer versions of NG use Vulkan by default, but can be configured.
-
Canta & AppMan
- Self-debloating is more likely to require factory-resets; because if removing an app makes the system unresponsive, you won't be able to go back to a working state (unless the removal is temporal and requires explicit input to become persistent, similar to GUIs that change screen resolution). You need an external device to recover without resetting.
- UAD-NG allows you to apply snapshots to multiple Androids, without installing anything on them. This allows you "centralize" debloating from one PC, which saves storage.
- You should be aware that granting "debug access" to a PC from an Android is essentially granting that privilege to all programs running on the PC. So if you suspect there's malware on your PC, then never connect your Android to that PC! (not even for USB file-transfer!).
TLDR: It's actually not possible.
All pre-installed APKs are in the /system partition. This partition is read-only, and only the OEM has the right to write to it through updates (OTA and/or wired), unless you unlock the bootloader.
System apps also use another partition: the /data partition (also called user-space). All the users' data and cache are stored in this partition. It basically stores all the modifications you have done in the device. All the apps you install are fully stored in there, including updated system APKs.
FYI, performing a factory-reset from recovery is simply doing a wipe of /data and a wipe of /cache.
Note
You understood right. A factory reset will restore all the debloated packages!
Without the right to mount /system as read-write, it is thus impossible to completely delete system packages from the phone. The only thing you can do is delete its cache and all the related user data. In the end, this method doesn't save significant storage space (unless you also uninstall the updates).
The good thing is you can prevent any package to be loaded in memory. That's the trick. Even after a reboot, those processes will not be waken up.
This software clears all the system bloat in /data and freezes these packages by uninstalling them for all the users. That means for the main user (id=0) and for any other user's profile.
More info here
- Disable:
- The app can be easily re-enabled by the system and/or you. However, if you try to enable it from the Settings app, some apps will have the button greyed-out, so you'll need UAD-NG to restore those.
- Can silently fail, causing the app to be immediately restored.
- Safest: minimal stability impact.
- Preserves updates, so you'll have to uninstall them manually
- Hidden from app drawer only. Can still be seen by Settings and 3rd-party apps that request
QUERY_ALL_PACKAGES. -
UAD*implicitlyclears the app data for you.
- Uninstall:
- The app can only be restored by a few privileged system components. Don't be confident.
- Unsafe: More likely to trigger instability. Some dependent apps may not realize their dependency doesn't exist, and continue trying to wake the non-existent app (see #670). This can drain battery faster.
- Likely to uninstall the updated APK of the selected app. More info here
- Mostly hidden: The app seems to no longer exist, but can still be listed using official Android APIs (yes, 3rd-party apps can see this)
- (Typically) a single command: No need to
clear, as Android does it on its own.
If you're debloating anything other than Recommended, you should disable rather than uninstall, as uninstalling is known to cause system stability issues.
If disabling fails try uninstalling, and vice-versa (see #632). Both seem to consistently fail on some packs (this is device-specific).
- If the package was restored immediately, then it's "protected" by the system in some way.
- If it was restored after a while, then a system-update could be the culprit.
Before Android 6.x (Marshmallow), pm disable <package> or pm disable-user --user <user> <package> can't be used without root permission.
Note
We recommend reading the logs, or the actual source code
Uninstall: pm uninstall --user <user> <package>
Restore: cmd package install-existing --user <user> <package>
Disable: pm disable-user --user <user> <package> + pm am force-stop --user <user> <package> + pm clear --user <user> <package>
Enable: pm enable <package>
Uninstall: pm hide <package> + pm clear <package>
Restore: pm unhide <package>
Uninstall: pm block <package> + pm clear <package>
Restore: pm unblock <package>
Uninstall: pm block <package> + pm clear <package>
Yes, but only in the sense that you can't brick your phone. You shouldn't encounter boot-loop but... We can't guarantee it 100%.
We try to list all the packages we came across. Even those you should not delete. Those are classified in the unsafe list. This way, you know the purpose of each package.
You can, for instance, freeze Play Store and Google Play Services (not recommended if you need WhatsApp, Discord, etc...). If you mostly use apps from F-Droid, de-googling shouldn't cause too much trouble.
Tip
If you want to "Un-Google" without major consequences, then you might be interested in GmsCore
If you plan to replace stock apps (Gallery, Videos etc...), then you might like Fossify
Chinese OEMs (especially Xiaomi and Huawei) have been "recycling" the IDs of AOSP packages for their own (modified & closed-source) apps. So filter by "AOSP" instead.
If we don't have the device, we can't do anything... but you do! and it will be very nice if you can do it! 😃
We'd gladly add your list into this software!
See the How to contribute section
The 1st thing to do is read the descriptions of your recently-removed packs, and restore the ones that might be related to the broken feature.
If that fails, you should do a binary search, similar to how git bisect works:
- Restore half of the apps you've uninstalled recently.
- If issue persists, restore the other half and (optionally) re-uninstall current half.
- If issue is fixed, re-uninstall half of the apps within the half you've just restored (quarter of total)
- Repeat until you've found the app you need
This method has some caveats:
- If the issue is caused by multiple apps being dependencies, it'll be hard to find which ones you should restore, as your selection may not be sorted
- In the worst case, there might be multiple layers of dependencies: where multiple apps are responsible for the same feature, and each app has multiple recursive dependencies
You could try a linear-search after a binary-search. That way, you can narrow the set of packs to a small group, then uninstall/restore one-by-one until you find the smallest set
Common steps to perform a full reset:
- Hold power and vol-down keys
- Wait for vibration
- Immediately (upon vibration), hold vol up key
- Proceed and perform a "clear data"
If that doesn't work, search on your web-search-engine of choice for "recovery mode <insert your device model or brand>"
- Open-source: UAD-NG is fully open-source, allowing anyone to inspect, contribute to, or modify the code. In contrast, ADB AppControl is not open source.
- Package descriptions: UAD-NG provides detailed, community-driven descriptions for packages, helping users make informed decisions. ADB AppControl does not provide package descriptions and relies on a single maintainer for updates and information.
- Cost: UAD-NG is completely free to use. ADB AppControl is not fully free—some features require payment or a license.
For more information about ADB AppControl, visit adbappcontrol.com.