-
Notifications
You must be signed in to change notification settings - Fork 103
FAQ
-
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 withExpertin the future. -
Expert-- Breaks widespread and/or important functionality, but nothing important to the basic operation of the operating system. Removing anExpertpackage should not bootloop the device (unless mentioned in the description) but we can't guarantee it 100%. -
Unsafe-- Can break vital parts of the operating system. Removing anUnsafepackage have an extremely high risk of bootlooping your device.
UAD write 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 logfiles from UAD-ng by pressing the Locate the logfiles button in the About section.
It's actually not possible.
All system apps are installed on the /system partition by the device manufacturer. This partition is read-only, and only the manufacturer has the right to write to it through updates (OTA and/or wired), unless you OEM-unlock your device, which then allows you to unlock the bootloader.
Tip
You don't need root, as fastboot mode (with unlocked bootloader) allows you to edit the entire file-system, or even format the storage with a different file-system.
Be warned: unlocking the bootloader will factory-reset. Android does this for security reasons.
root is just convenient, because it gives you runtime privileges, at the cost of being very unsafe!
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 apps.
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 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).
Important
Disabling/Uninstalling a pack does not uninstall its updated version. This is a limitation of ADB, there's nothing we can do, unfortunately.
However, if you're lucky, your device might actually uninstall the updates for you
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 you, via Settings app).
- Can silently fail, causing the app to be immediately restored.
- Safest: minimal stability impact.
- 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.
- 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. - More likely to uninstall the updated APK of a pre-installed app.
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. 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, as this documentation can quickly become outdated.
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...) by other apps, we'd like to propose the install of FOSS replacement, stay tuned.
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 "