Missing option to exclude individual apps from automatic updates in App Lounge

I searched a lot, but haven’t found any option to exclude individual apps from automatic updates.

Whereas it is usually desirable to have all apps up-to-date, this is counterproductive in some cases, e.g. when an app’s newer version doesn’t work anymore with the system; I have such a case in my apps, guessing that this might be caused by microG instead of the original Google framework (btw, I love the replacement of Google’s closed source framework with microG - just to avoid any misunderstandings :grin:).

But while others offer this feature, from F-Droid and its alternative stores to even the original Google App Store, I haven’t found that option at the App Lounge (currently running App Lounge version 2.16.1).

The only possibility I found is to disable the automated update completely, but that comes with the major drawback of having to install all updates yourself on a regular basis.

  • Did I miss something?
    Is it perhaps possible to do this using configuration files, for example?

Open App Store> Settings > uncheck Automatically install updates. This is how I have my phone set so you know what is getting updated. My version is the same as yours 2.16.1.

The updates are not that often so doing them is a minor task.

That doesnt really answer the question. He has a point, if there is only one APP on your phone that has to stay in a specific Version, Individual settings would be a great benefit. I dont think there is an Option.

Hi @Jets ,

thanks for the answer, but @mehoranto is right - I’m looking for a possibility to exclude only one app (or just a few ones) from the automated update.

For sure, I may disable the automated update completely and perform all App updates manually - that’s the reason I already mentioned that option in my original, first post; but actually I was happy to get rid of that task with /e/OS.

Sadly, it looks like there’s no other way than doing so. I don’t understand how such a basic feature could have been overlooked during implementation!
So I was still hoping for some kind of blacklist where you could manually enter apps—perhaps via text—that would then be excluded from the update.

As far as I got it, programming of /e/OS has an agile approach with the backlog task’s priorities being voted by the community, right?

So if there isn’t such an issue already existing (I haven’t found any up to now), I should open one, hoping that others find it useful as well and will vote it up.

3 Likes

When you have “Automatically install update” turned off, the app store will notify if there are updates available. So when it does just install the updates you need.

Alternately you could just us Aurora Store as you can make separate black lists.

Thanks for your suggestion - Aurora Store is a workaround worth trying.
Nevertheless, it still remains a workaround: One more app eating up a bit of system memory, running in background…

Btw, your post gave me an additional idea:
If I were to suggest implementing a feature for custom updates per app at e foundation’s GitLab, users should be able to choose between three statuses per app

  1. Automated update (only possible behaviour at the moment with automatic updates globally being enabled; should remain the default),
  2. notification about app updates, but don’t update them automatically (to review changes before accepting them),
  3. ignore any update completely (i.e. no notifications for updates either).

I don’t know if this is implemented in a any app store, but it would be handy.

“version pinning” is an accurate term to search for in the backlog. I can find a few old issues (3+) on this on the AppLounge label.

Feature/bug voting would be great to have here in the forum, as most will not reach for the gitlab.

Thanks for the hint - I would never have thought of that term otherwise!

I agree - but I guess (or fear?) that the programmers won’t look here but are only driven by the GitLab voting . :confused:

Anyway, it would be nice if it was possible to “bundle” all old issues in GitLab to only one issue, including all votes, to get more “voting power”. :wink: