After so long of developing apps for other people, I've decided to make one 100% by myself, and publish it.
The app is basically an alternative to the default app-manager of Android, and it provides some unique features that helps you manage and uninstall apps quicker and easier.
If you've found this app useful, please support it by sharing/donating/comment on the play store.
Installation link :
APK mirror:
https://www.apkmirror.com/apk/androiddeveloperlb/app-manager/
ApkPure:
https://apkpure.com/app-manager/com.lb.app_manager
Some screenshots
So, here's some information about it:
Background
How many times have you tried to uninstall an app but found it annoyingly hard, whether you've forgot its name or it's hidden in a bunch of many apps you have?
Have you ever wanted to uninstall a built in app, which came from the carrier/manufacturer?
Are you a programmer/tester and need to uninstall/reset your apps frequiently?
If so, this is the app for you.
Short description
As I've written ,the purpose of this app is to replace the default app-manager, and ease the uninstallation task as much as possible.
The app is free and supports Android 2.3 and above, but works best from Android 4.0.
The app has ads (banners) but you can easily remove them by donating.
Who is it useful for?
The app is intended for multiple kinds of people:
Features and advantages over other apps
App translation
https://crowdin.com/project/com-lb-app_manager
Beta testing
Links for the beta testing group:
- https://play.google.com/apps/testing/com.lb.app_manager
Articles
FAQ
The OS says the app runs in the background, or the app has a notification of its own. Why? Doesn't it consume battery?
The app is triggered by app operation events : uninstall, install, clear-data...
Upon each of those, it saves the state for various purposes, in the background. For example the removed-apps list, and the widget. Those have to be handled right away, so it must be done even if you don't see the app.
In the rest of the time, it does absolutely nothing.
This is why the app is so efficient in battery usage, that you won't see it in the list of battery-consuming apps. Meaning it doesn't even reach the 1% battery usage. I am sure it doesn't even reach 0.001% .
You can hide the notification, but sadly on some Android versions (8.0, but not 8.1 and above) you might see a different notification, that the app might use the battery. You can safely ignore it. I guarantee there is no noticeable difference in battery consumption.
In fact, due to the optimizations I've added for Android 8.0 and above, and because the app's process doesn't get killed so often, it might even be better in battery usage. The reason is that the app always had to listen to app-events, and before Android 8.0, the app got triggered by them, meaning its process started each time if it was killed before. Less CPU, more battery.
I have a Xiaomi device and the app fails to install any kind of app. How come ?
Seems it's an issue that will exist for quite some time, and that it is turned by default on Xiaomi devices and causes various issues (read here for example). This "feature" is called "MIUI optimization" , and for now you can only disable it on the "Developer options".
So, for now, you can overcome this by enabling developer options and there to disable "Turn on MIUI optimization".
Note that once you do this, the OS will reset a lot of apps, mainly in terms of permissions. This includes my app too.
Just a side note: Xiaomi is known as one that breaks a lot of apps, as it creates its own made up rules and permissions, very much against how Android works. This is also why there is a website that speaks about it, here, so for better handling of the app, also white list it from the various permissions Xiaomi has created, too.
Sadly I have no way to handle those things, as long as Xiaomi chooses to make their own non-standard rules.
I don't have a rooted device, but I still want to disable/uninstall a system app. Is it possible?
It's possible... to try, using a PC connected to your device.
I've made a tutorial for this here (old one here ).
If the OS would allow, you could uninstall or at least disable system apps this way.
I think I got some nasty app, which shows ads randomly or takes control of the smartphone in some way (or any other bad behavior that I don't like). Can this app help me find it and neutralize it?
Even though it wasn't originally intended for such a task, I've noticed it helped many people with it. There are multiple reviews telling that it helped them removing such "virus" apps. I've even done it myself on both my device and for my family-relatives.
So the answer is that it might help you. Here's what you can do to try to handle it:
https://xdaforums.com/showpost.php?p=77987186&postcount=543
What are split-APK files? What are "APKS" that are being generated sometimes when sharing apps?
Split apk files (AKA "app bundle" apps) are not meant to be installed just like normal APK files. They are used as you use the app, getting installed by the Play Store, to use only the minimal things you will use on your device, with your Android version, with your CPU architecture, with your locales, with your screen density, and so on...
Not only that, but if you install such files on other configurations, they might not work properly or fail to install.
As far as I know, backup&restore of such apps is not even working on popular backup apps such as Titanium backup.
Currently the app allows to share such apps as APKS files, which is just a zipped file with all of the APK files of the app. This is similar to what's done on various other apps and services (SAI, ApkPure, APK-mirror,...) with various file extensions (APKS, XAPK, APKM,...).
To install them using my app (which supports all files that I've mentioned: APKS, XAPK, APKM ), you can currently do this only from other apps that trigger it. The most common way to do it is directly from file-manager apps, but this should also be possible via chatting apps and others.
If you wish to do it on your via the PC, you can do it too:
use adb command as such:
Why isn't there a permissions management feature?
For permissions management, I actually planned some management tool, but sadly Google has changed how permissions groups work, and so permissions sometimes go to a different group. For example, before Android P, the permission "WRITE_CALL_LOG" belonged to "Phone" permission group, but from Android P, it moved to "Call log" permission group, which never existed before.
Currently, Google removed all APIs to get which permission group has which permission. Even in the documentation there is no mention anymore which permission group holds which permissions. Not only that, but OEMs sometimes make up their own permission which aren't official in any way (see "auto start" that Xiaomi made, and the reason that "don't-kill-my-app" website exists, for example). I still hope that one day I will be able to get a reliable way to get the correct information, no matter which version of Android the app runs on.
Why isn't there an option to install an old version of an APK when I have a newer one installed?
Apps aren't designed to handle this situation. They are only designed to handle upgrades. So, Google made it impossible to do it starting from Android 7 (read here). If you want to try it anyway, you can do it using PC&adb tool, as written here.
Why isn't there a boot-up management feature? Memory freeing/boosting? CPU usage? RAM usage? Automatic-task-killing? Modify apps ?
Various features of those types are not documented and not recommended to be used. Those can ruin how the apps work, just like OEMs do it sometimes even by default. This can also cause false crashes, or crashes that can't be reported. For users, some of those functions have the false promise by various apps that say it will make reduce battery consumption (search google for "Android task killer myth").
It is not a good thing to alter how apps work and behave, and Google has rules about modifying APKs, so I do not want to take the risk in doing so.
As for viewing information alone, this is something that isn't useful for users, but more for developers who already have them via the various development tools and even apps that specialize about it.
This app was made for users and power users mostly, and I want to make it work properly as much as possible, without worrying that for some devices or at some day things will be broken. I prefer to have as little workarounds as possible.
That's why I decided to stick with things that are more standard, more commonly used, and more available to be used.
I have an SD-card. Why can't I set an installed app to be on it, properly?
Installing an app to the SD-card has various restrictions that determine whether it's possible or not, and how much it will affect how well the app behaves.
To do it here, you have to have a rooted device (or use a PC with adb command as written above), the OS should allow to do it, and the target app should allow to do it.
That being said, you might try your luck via the developer-settings of the OS (check how to enable it on Google for your device), via "force allow apps on external" preference.
Why not share version-name and app-name alone instead of version-code and package-name with others?
Simply put, version-name and app-name are not unique enough, depend on the current locale, can be of any length (so it can be too long) and not restricted by which characters are used (so can be problematic on some OSs).
That's while version-code is always an increasing number, and package-name is always safe to use and is considered as the ID of the app on the Play Store and probably on any app-store.
That being said, I might allow to customize what to share some day, and let users be responsible of possible issues if they might occur.
In the past versions, the app didn't need to run in the background, and didn't need to have usage-stats permission at all. What happened?
In one word: Google . Google has changed the rules:
- For running in the background , the reason is that a lot of types of global events (called "Intents") need to be handled only with an app that has a sticky notification (called "foreground service"). Before Android 8.0, it was possible without this requirement. The app would have been awakened for each such event, handle it and go to sleep, while the OS can kill it if needed. Now it's not possible (read here). Adding to this, is that Google forces all new apps and updated to existing ones to do it for Android 8.0 and above, by the end of the year (read here). This means you should expect more apps to show their notifications, or they will present a weaker functionality.
The good news is that this actually helps with battery usage on Android 8.0 and above. Instead of re-creating the process of App-Manager for each event, the process is already alive, so less CPU will be used. And, since it's already alive, handling it will take less time. So, less CPU and less time, meaning more battery for you. You can also hide the notification if it bothers you.
- For usage-stats permission, before Android 8.0 I could get the exact app-size without any permission. And, before Android 5.0, I could get the recently launched apps with a permission that doesn't require requesting in runtime. Because of the recent changes, this is not possible anymore without usage-stats permission. And, since getting app-size and sorting apps by recently launched - are quite basic features, I decided to request it all in the beginning together with the storage permission that was always a requirement.
Getting the app-size was tricky before Android 8.0, and so I added a fallback in case it's not working for some users, or working too slow for them. It wasn't perfect, but it was all I could do.
The good news about this, is that it's much more efficient than what I did before. Getting app size is super fast, and it will always work because there is now an official way to do it. In fact it's so quick that I've removed the fallback for Android 8.0 and above.
Privacy policy ?
Written on this post.
The app is basically an alternative to the default app-manager of Android, and it provides some unique features that helps you manage and uninstall apps quicker and easier.
If you've found this app useful, please support it by sharing/donating/comment on the play store.
Installation link :
APK mirror:
https://www.apkmirror.com/apk/androiddeveloperlb/app-manager/
ApkPure:
https://apkpure.com/app-manager/com.lb.app_manager
Some screenshots
So, here's some information about it:
Background
How many times have you tried to uninstall an app but found it annoyingly hard, whether you've forgot its name or it's hidden in a bunch of many apps you have?
Have you ever wanted to uninstall a built in app, which came from the carrier/manufacturer?
Are you a programmer/tester and need to uninstall/reset your apps frequiently?
If so, this is the app for you.
Short description
As I've written ,the purpose of this app is to replace the default app-manager, and ease the uninstallation task as much as possible.
The app is free and supports Android 2.3 and above, but works best from Android 4.0.
The app has ads (banners) but you can easily remove them by donating.
Who is it useful for?
The app is intended for multiple kinds of people:
- For the common user, it's easier to perform searches of apps, easier to unisnstall them, and easier to share them.
It's also easier to go to the play store page of the app ,give feedback about it and contact the developers. - For power users, it's easier to uninstall built in apps (AKA "system apps"), like the bloatware that come with the OS.
- For developers, QA, and beta testers, it's easier to uninstall/reset the recently installed app, by using widgets.
You can also share apps as APK files, and see the version of the apps.
Features and advantages over other apps
- Viewing of app types of apps, and not just those that you can launch (example: plugins, live wallpapers, keyboards,...).
- Widgets, for quick uninstallation/reset of the most recently installed app.
- Quick uninstallation of apps. For rooted devices, the uninstallation (and other operations) can be silent (in the background)
- Easy uninstallation of apps that got admin privilages.
- Ability to automatically add app shortcuts when they get installed, no matter how they got installed.
Also the ability to choose which launcher will create the shortcuts. - Easy to use - one click to uninstall. Long click for multi-selection
- Context menu options on selected app:
- Run
- Share Play store link, Amazon AppStore link, or even APK file (no need for Root)
- Manage
- Open app on the Play store.
- Kill background process, or stop the app (needs root)
- Quick reset of the app (needs root).
- disable/enable app (needs root).
- Create shortcut.
- Search the app via your search engine or the Internet.
- Sort the apps bysize, name, by package name, by date installed, and by date updated
- Filter apps by:
- System/user apps,
- Enabled/disabled apps
- Installation path : SD card / internal storage
- Ability to uninstall system apps (Root only, and might not work on some cases)
- Ability to replace the default uninstaller .
- Detailed yet short view of the installed apps, including app name, package name, date insalled and version information.
- Safe and automatic deletion of certain folders after uninstallation, that some Android OS versions don't handle for some reason.
- Theme chooser, in case you don't like the cards UI.
- Hopefully more to come, will be written about on the play store
App translation
https://crowdin.com/project/com-lb-app_manager
Beta testing
Links for the beta testing group:
- https://play.google.com/apps/testing/com.lb.app_manager
Articles
- https://web.archive.org/web/2014050...roid/supercharge-your-android-app-management/
- http://reviewttb.blogspot.in/2014/04/app-manager-review.html
- http://iandroid.co.il/dr-iandroid/archives/16296
- http://www.appbrain.com/app/app-manager/com.lb.app_manager
- https://www.androidrank.org/application/app_manager/com.lb.app_manager
FAQ
The OS says the app runs in the background, or the app has a notification of its own. Why? Doesn't it consume battery?
The app is triggered by app operation events : uninstall, install, clear-data...
Upon each of those, it saves the state for various purposes, in the background. For example the removed-apps list, and the widget. Those have to be handled right away, so it must be done even if you don't see the app.
In the rest of the time, it does absolutely nothing.
This is why the app is so efficient in battery usage, that you won't see it in the list of battery-consuming apps. Meaning it doesn't even reach the 1% battery usage. I am sure it doesn't even reach 0.001% .
You can hide the notification, but sadly on some Android versions (8.0, but not 8.1 and above) you might see a different notification, that the app might use the battery. You can safely ignore it. I guarantee there is no noticeable difference in battery consumption.
In fact, due to the optimizations I've added for Android 8.0 and above, and because the app's process doesn't get killed so often, it might even be better in battery usage. The reason is that the app always had to listen to app-events, and before Android 8.0, the app got triggered by them, meaning its process started each time if it was killed before. Less CPU, more battery.
I have a Xiaomi device and the app fails to install any kind of app. How come ?
Seems it's an issue that will exist for quite some time, and that it is turned by default on Xiaomi devices and causes various issues (read here for example). This "feature" is called "MIUI optimization" , and for now you can only disable it on the "Developer options".
So, for now, you can overcome this by enabling developer options and there to disable "Turn on MIUI optimization".
Note that once you do this, the OS will reset a lot of apps, mainly in terms of permissions. This includes my app too.
Just a side note: Xiaomi is known as one that breaks a lot of apps, as it creates its own made up rules and permissions, very much against how Android works. This is also why there is a website that speaks about it, here, so for better handling of the app, also white list it from the various permissions Xiaomi has created, too.
Sadly I have no way to handle those things, as long as Xiaomi chooses to make their own non-standard rules.
I don't have a rooted device, but I still want to disable/uninstall a system app. Is it possible?
It's possible... to try, using a PC connected to your device.
I've made a tutorial for this here (old one here ).
If the OS would allow, you could uninstall or at least disable system apps this way.
I think I got some nasty app, which shows ads randomly or takes control of the smartphone in some way (or any other bad behavior that I don't like). Can this app help me find it and neutralize it?
Even though it wasn't originally intended for such a task, I've noticed it helped many people with it. There are multiple reviews telling that it helped them removing such "virus" apps. I've even done it myself on both my device and for my family-relatives.
So the answer is that it might help you. Here's what you can do to try to handle it:
https://xdaforums.com/showpost.php?p=77987186&postcount=543
What are split-APK files? What are "APKS" that are being generated sometimes when sharing apps?
Split apk files (AKA "app bundle" apps) are not meant to be installed just like normal APK files. They are used as you use the app, getting installed by the Play Store, to use only the minimal things you will use on your device, with your Android version, with your CPU architecture, with your locales, with your screen density, and so on...
Not only that, but if you install such files on other configurations, they might not work properly or fail to install.
As far as I know, backup&restore of such apps is not even working on popular backup apps such as Titanium backup.
Currently the app allows to share such apps as APKS files, which is just a zipped file with all of the APK files of the app. This is similar to what's done on various other apps and services (SAI, ApkPure, APK-mirror,...) with various file extensions (APKS, XAPK, APKM,...).
To install them using my app (which supports all files that I've mentioned: APKS, XAPK, APKM ), you can currently do this only from other apps that trigger it. The most common way to do it is directly from file-manager apps, but this should also be possible via chatting apps and others.
If you wish to do it on your via the PC, you can do it too:
use adb command as such:
Code:
adb install-multiple apk1 apk2 ...Why isn't there a permissions management feature?
For permissions management, I actually planned some management tool, but sadly Google has changed how permissions groups work, and so permissions sometimes go to a different group. For example, before Android P, the permission "WRITE_CALL_LOG" belonged to "Phone" permission group, but from Android P, it moved to "Call log" permission group, which never existed before.
Currently, Google removed all APIs to get which permission group has which permission. Even in the documentation there is no mention anymore which permission group holds which permissions. Not only that, but OEMs sometimes make up their own permission which aren't official in any way (see "auto start" that Xiaomi made, and the reason that "don't-kill-my-app" website exists, for example). I still hope that one day I will be able to get a reliable way to get the correct information, no matter which version of Android the app runs on.
Why isn't there an option to install an old version of an APK when I have a newer one installed?
Apps aren't designed to handle this situation. They are only designed to handle upgrades. So, Google made it impossible to do it starting from Android 7 (read here). If you want to try it anyway, you can do it using PC&adb tool, as written here.
Why isn't there a boot-up management feature? Memory freeing/boosting? CPU usage? RAM usage? Automatic-task-killing? Modify apps ?
Various features of those types are not documented and not recommended to be used. Those can ruin how the apps work, just like OEMs do it sometimes even by default. This can also cause false crashes, or crashes that can't be reported. For users, some of those functions have the false promise by various apps that say it will make reduce battery consumption (search google for "Android task killer myth").
It is not a good thing to alter how apps work and behave, and Google has rules about modifying APKs, so I do not want to take the risk in doing so.
As for viewing information alone, this is something that isn't useful for users, but more for developers who already have them via the various development tools and even apps that specialize about it.
This app was made for users and power users mostly, and I want to make it work properly as much as possible, without worrying that for some devices or at some day things will be broken. I prefer to have as little workarounds as possible.
That's why I decided to stick with things that are more standard, more commonly used, and more available to be used.
I have an SD-card. Why can't I set an installed app to be on it, properly?
Installing an app to the SD-card has various restrictions that determine whether it's possible or not, and how much it will affect how well the app behaves.
To do it here, you have to have a rooted device (or use a PC with adb command as written above), the OS should allow to do it, and the target app should allow to do it.
That being said, you might try your luck via the developer-settings of the OS (check how to enable it on Google for your device), via "force allow apps on external" preference.
Why not share version-name and app-name alone instead of version-code and package-name with others?
Simply put, version-name and app-name are not unique enough, depend on the current locale, can be of any length (so it can be too long) and not restricted by which characters are used (so can be problematic on some OSs).
That's while version-code is always an increasing number, and package-name is always safe to use and is considered as the ID of the app on the Play Store and probably on any app-store.
That being said, I might allow to customize what to share some day, and let users be responsible of possible issues if they might occur.
In the past versions, the app didn't need to run in the background, and didn't need to have usage-stats permission at all. What happened?
In one word: Google . Google has changed the rules:
- For running in the background , the reason is that a lot of types of global events (called "Intents") need to be handled only with an app that has a sticky notification (called "foreground service"). Before Android 8.0, it was possible without this requirement. The app would have been awakened for each such event, handle it and go to sleep, while the OS can kill it if needed. Now it's not possible (read here). Adding to this, is that Google forces all new apps and updated to existing ones to do it for Android 8.0 and above, by the end of the year (read here). This means you should expect more apps to show their notifications, or they will present a weaker functionality.
The good news is that this actually helps with battery usage on Android 8.0 and above. Instead of re-creating the process of App-Manager for each event, the process is already alive, so less CPU will be used. And, since it's already alive, handling it will take less time. So, less CPU and less time, meaning more battery for you. You can also hide the notification if it bothers you.
- For usage-stats permission, before Android 8.0 I could get the exact app-size without any permission. And, before Android 5.0, I could get the recently launched apps with a permission that doesn't require requesting in runtime. Because of the recent changes, this is not possible anymore without usage-stats permission. And, since getting app-size and sorting apps by recently launched - are quite basic features, I decided to request it all in the beginning together with the storage permission that was always a requirement.
Getting the app-size was tricky before Android 8.0, and so I added a fallback in case it's not working for some users, or working too slow for them. It wasn't perfect, but it was all I could do.
The good news about this, is that it's much more efficient than what I did before. Getting app size is super fast, and it will always work because there is now an official way to do it. In fact it's so quick that I've removed the fallback for Android 8.0 and above.
Privacy policy ?
Written on this post.
Attachments
Last edited:
