Save battery and data leak with an automatic app disabler

[fla]

Hello everyone,

Our phone is always running plenty of apps, and they are always running many things without us really needing it. I am often finding myself killing apps to be sure they don’t use my battery and my data for nothing, and also because I don’t trust them if they are not FOSS. For example, I don’t need Spotify to run when I am not listening to music (and check for “upcoming concerts next to my area” and things like this).
Android has a way to disable an app (which is lighter than uninstalling it, but stronger than killing its process). My suggestion is to add a mechanism inside /e/ OS which would:

• Allow users to decide which app should stay “always enabled” and which ones should be “disabled when not used”
• When an app in the “disabled when not used” category is stopped (sliding the app to the top to stop the process), then /e/ OS would actually fully disable the app
• The app should still be visible in the launcher and when the users tap on it, should be re-enabled on the fly and started, as done usually

Technically, this can be done either with pm disable PACKAGE, but that would hide the app so the mechanism would need to still display a fake icon. There is also cmd package suspend PACKAGE which keeps the package visible in the launcher, I’m unsure how “strong” this is though.

What do you think?

[Didou]

Hello FLa,

this sound like a good idea, but it need dev time to be realized. Actually, the e/OS / Murena team may not have the available time right now because they are still trying to recover from the outage.

I’m curious about the other’s opinion about this idea, though !

EDIT : found this, did you already try, @fla ?

[tominer]

As workaround you can use the FOSS Apps shizuku and hail for that.

[jollajo]

Would you mind to expand how those apps work?
Couldn’t find shizuku and from the description of hail it’s not quite clear to me how that works.
What is the workflow to launch and terminate an app?

Do those apps require root access?

[KernelPanicake]

Looks interesting. What about using suspend with this app? Is suspend just force quitting the app? Or will it also prevent it from running in background?
I dont really want to disable apps, just not have some of them running in background.

[tominer]

Hail is a free-as-in-freedom software to freeze Android apps. Enjoy all features freely!

Freeze

Freeze is a word to describe the action of forbid apps when they are unnecessary
to use device
in a better way, cut down the usage of ram and save power. User can unfreeze it to revert.

In general, “freeze” means disable, but also Hail can “freeze” apps by hiding
and suspending them.

Disable

Disable apps will not shown in launcher. Enable them to revert.

Hide

Hidden apps will not shown in launcher and installed app list. Unhide them to revert.

Suspend

Suspended apps will be shown as grayscale icons in the launcher. Unsuspend them to revert.

Working mode

Hail can work with Device Owner, Dhizuku, Superuser (Root) and
Shizuku (including Sui).

---

When developing apps that requires root, the most common method is to run some commands in the su shell. For example, there is app uses pm enable/disable command to enable/disable components. This method has very big disadvantages:

Extremely slow (Multiple process creation)

Needs to process texts (Super unreliable)

The possibility is limited to available commands

Even if adb has sufficient permissions, the app requires root privileges to run

Shizuku uses a completely different way. The most important feature Shizuku provides is something like be a middle man to receive requests from the app, sent to the system server, and send back the results. To the app, it is almost identical to the use system APIs directly. But it’s much faster as it hooks into the system directly.

Several apps already use Shizuku. If you want to integrate it with yours, take a look at the Developer guide. For users, there’s also a User guide.

[Denis2ni]

I agree, it will be fine if such a app disabler will be included in /e/os.
For my part, since many years, I use Superfreezz to do that. This application is opensource and doesn’t need to be rooted.
clic here to know more

[rikshaw]

Until now I had used Shelter to put apps I wanted to freeze in the work profile and set them to auto freeze. This gives isolation too. But I am giving superfreezz a try, this is the first I had heard of it. I may move to it because I suspect having the full separate work profile is causing some efficiency loss greater than with superfreezz just working in the main profile.

Thanks for the suggestion!

[KernelPanicake]

Super freeze looks nice too, but seems to be outdated (last update on F-Droid 2 years ago) and doesnt seem to be updated for Android 14 yet…

It does start on Android 14 though, but cant be set as accessibility tool. (Dont know what exactly its callled in english)

After some research it seems the app will need an update for android 14

[N200]

I totally agree with you and support this suggestion.

Piggybacking, before adopting /e/os I was on LineageOS and I was pretty happy with Kill foreground app feature which truly killed running apps. (Settings > Buttons > Long swipe action)

Unfortunately, it is not available in /e/os. When “closing” apps here, they simply go away from the BlissLauncher but the process keeps on running.

I haven’t seen any updates on a feature request submitted on this

Kill foreground app (request)

Settings > Buttons > Long swipe action > Kill foreground app. This isn’t available in e-2.0-t-20240507399779-dev-dre.zip I could not see anything similar in dev options either. As it stands, swiping up makes the app go away. Going to Configuration > Apps > App Info; shows app still running as Force stop is displayed. When killing the app, force stop is grayed out meaning the app is not running. Thanks,

Additionally, I think Android itself is becoming unmanageble in terms of power/battery consumption with the increasing amount of background system services…

[Denis2ni]

Hello KernelPanicake
It is true that I use Superfreezz with my Samsung S7 (/e/os S) and my Samsung S10e (/e/os T). I will see soon when the Galaxy S10e will be with /e/os U (android 14)…

[Denis2ni]

Hello N200,
For information, in previous versions of /e/os, there was (in the developpers options) the possibility to allow a long press action to kill the current app. I had selected this option to allow killing of current app with a long press to the current app button. In new versions of /e/os this option has desappeared of the developpers options, but my long press button is still operationnal! I could still use it to kill the current app.

(“Arrêter l’application en cours” is french for “Kill the current app”).
Even with the new version of /e/os, I continue to use it with my two phones Samsung Galaxy S7 and S10e.
I think it will not be very difficult for the /e/os developpers to reactivate this option in the developpers options… Suggest them to do so…

[N200]

Salut Denis,

Merci pour votre response.

Oh yeah. I looked for it myself and it is not showing for my device.
Weird but that’s how it is.

That’s why I submitted the request enhacement few months ago.