-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(pkg-state): We should consider disabling apps IN ADDITION to uninstalling them #670
Comments
Maybe I'm missing something here, but I don't entirely understand: if you uninstall, and it succeeds, then how you want to disable an app? After all, the app is gone from the device, so it can't be uninstalled. Even if you disable first, then uninstall, other apps will still see it's no longer present. In my opinion a better feature is to detect whether uninstalling fails. If so - for example due to the lack of permissions - automatically try disabling instead. |
@AnonymousWP Thanks for your response.
Android allows both uninstalling and disabling apps with ADB. Yes, it's weird, and it doesn't make much sense logically (I suspect its something to do with the fact that the app is still available on the system partition, but uninstalled on the user level). You can test this out and see for yourself. The problem is that when apps are only uninstalled via ADB (& not also disabled), the other apps on the device can't see that they're uninstalled, and may try calling them as a dependency or communicate for certain functionality. (Again, I think this is probably related to the fact that the app is still on the system partition even though we uninstalled it for the user, so apps on the device still think its available, but when they try to call it... of course nothing is there, it isn't present, so it might crash & causes issues, as I highlighted in my examples above). However, apps on the device are able to detect when an app is disabled, meaning rather than trying to call the uninstalled app that doesn't exist, when it's also disabled, the app can fallback appropriately & won't crash or display error messages.
Simple. (Replace
Like I said above, feel free to test this yourself, and I think you'll see what I mean. |
I'll test the "hack" when I have some free time.
#632 (I'm mentioning it to link the issues together). If both issues are "closed as completed" then this implies there would be no need for fail-detection, as the pack will already be disabled by the time UADNG notices the error (unless the This might be order-sensitive and device-dependent, so we have to ask users to test both |
Describe the feature you want
Hi there,
Thank you for your great work on this project.
I believe that when uninstalling an app through UAD, rather than only uninstalling it, we should uninstall and disable the app.
(Yes, it is possible to do both... Android is weird sometimes :p).
The reason I think this would be worth pursuing is that I have noticed instances where uninstalling apps alone causes breakage, as other apps on the device think the app is still installed, so they will still try to call the app as a dependency. But of course... the app doesn't actually exist since we uninstalled it. The end result causes unnecessary issues & breakage. When an app is both disabled & uninstalled, this is no longer a problem, as the app can see the dependent app is unavailable and fallback appropriately.
For examples:
All 3 of these examples are with Play Services - but I imagine there are many other cases like this, especially with different system apps. In fact, I honestly wouldn't be surprised if this causes a majority of the issues people have when debloating & removing certain apps from their device. I believe that this if this change is implemented, it would fix a lot of problems.
To sum up my proposal:
disable
feature as is.uninstall
to both uninstall and disable apps, rather than only uninstall it.I'm curious to hear thoughts on this - I'm not aware of any downsides this would introduce, but I'm curious if there's something I'm missing?
🙏
Acknowledgements
The text was updated successfully, but these errors were encountered: