-
Notifications
You must be signed in to change notification settings - Fork 171
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
-
Recommended
-- Any package that's safe to uninstall (this will change), and/or apps available through whatever app-store is built-in (G Play, Samsung Galaxy Store, etc...). Despite being "safe to remove", you should review them anyways, as different people have different needs and preferences. -
Advanced
-- Breaks obscure or minor parts of functionality, or apps that aren't easily enabled/installed through Settings/Google Play. This category is also used for apps that are useful (default keyboard/gallery/launcher/music app.) but that can easily be replaced by a better alternative. This removal-type might be merged withExpert
in the future. -
Expert
-- Breaks widespread and/or important functionality, but nothing important to the basic operation of the operating system. Removing anExpert
package should not boot-loop the device (unless mentioned in the description) but we can't guarantee it 100%. -
Unsafe
-- Can break vital parts of the operating system. Removing anUnsafe
package have an extremely high risk of boot-looping your device.
UAD-ng writes logs to the user’s cache directory (see more)
-
Linux:
$XDG_CACHE_HOME/uad
or$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.
- 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_BACKEND
environment-variable togl
before opening UADNG, which is more likely to be compatible with your hardware, as it usestiny_skia
instead 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.
- 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*
implicitlyclear
s 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).
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 bootloop 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
If I don't have the phone on hand, I 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>"