Figure Out Silent/Background Updates about obtainium HOT 82 CLOSED

Just leaving a note that this new plugin uses a permission that is not allowed for Play Store apps, which I guess is part of why Droidify, Neo-Store, etc. are not there. Took down the Play Store listing as it's not as important as having silent updates.

from obtainium.

I don't think it's an app's responsibility to fill in those gaps via unsupported/hacky methods.

Most apps provide a Root/Shizuku installation method alongside the normal ones, so you can do it too. And I don't know about the "hacky" method; they're simply another way to install an app.

Also the majority of users may be on Android 11 and lower but I doubt that many are rooted.

You can use Shizuku, but it seems like there aren't any Shizuku plugins for Flutter yet. At least you can provide root installation for Android 11 and below, unless you don't want to support this use case.

from obtainium.

Is it possible to add silent installations with root permissions, like fdroid? Maybe a toggle in the settings to choose silent installation method (when other methods are available). I think having Root and Shizuku as options would be nice.

Love the app, by the way. Thank you.

from obtainium.

Okay, silent/background installs seem to work in my very limited testing, but it needs a lot more testing before release. Zips attached, please help test if interested.

app-arm64-v8a-release.zip
app-armeabi-v7a-release.zip
app-release.zip
app-x86_64-release.zip

Some things to note:

• Background installs are done on a "best effort" basis, meaning there's no way to know whether an update was installed successfully or not until you actually open Obtainium and check (the notification even says "App Updates Attempted" instead of "App Updated"). I haven't encountered a case where this fails though, since updates are only attempted if they satisfy specific criteria.
• Obtainium's version number for these APKs is higher than the current GitHub release, so ignore that update button.

from obtainium.

@matchboxbananasynergy thanks for mentioning APKUpdater, I took a look at their code and found a couple of flags that were missing from the Flutter plugin. After adding those, silent updating on Android 12+ works for apps targeting SDK 14+, at least when doing so from the foreground Flutter process. For now the main benefit is fewer button presses - you only need to tap "Update" once to update multiple apps instead of having to additionally go through the confirmation prompt for each install: https://github.com/ImranR98/Obtainium/releases/tag/v0.13.24-beta

Unfortunately when I last tried using this plugin from a background process a few months ago, it would error out. That probably hasn't changed (didn't have time to check, will do so later this week). So the issue is still unresolved.

from obtainium.

The one mentioned in this thread 👆

UPDATE_PACKAGES_WITHOUT_USER_ACTION

from obtainium.

@mike-lloyd03 Yes, that permission lets you update in the background if the App is one that you installed initially (no user interaction needed after the initial install).

The issue is that Obtainium is written in Flutter so it cannot use any Android APIs directly. We need a Flutter plugin that supports installing and updating Apps through the new session-based API. As of now, the only installer plugins available that I have seen all use the old intent-based method which doesn't support background updates (either that or they claim to use the new method but are broken and unmaintained).

I can't write such a plugin myself since I have zero native Android dev experience (plus Flutter has a weird way of interfacing with the native side, making things a bit more complicated). I might take the time to learn at some point but probably not anytime soon.

This plugin may work at some point: playbott/android_package_installer#1 (comment)

from obtainium.

Newer versions of Android allow you to silently update apps that you installed, using a normal supported API. Using something like Shizuku or ADB seems like overkill for something like this (and more difficult than the normal API method).

You have to consider users lower than Android 12 (which I think is the majority, over users using Android 12 and higher). A quick search shows these plugins supporting root installation:

https://github.com/irvine1231/flutter_app_installer
https://github.com/ShadyBoshra2012/flutter_install_apk_silently
https://github.com/amorenew/Flutter-Root-installer

from obtainium.

Strongly disagreed, the app shouldn't hold your hand, you should be able to allow it to auto-update and install in the background. What you're describing is basically no different than the current functionality, no one is stopping you from using it as it is, but that's not the feature request.

from obtainium.

Almost there - silent background installs are now working on my fork of that plugin, but there is no way to get the install result (meaning no way to do installs synchronously in a background process) - more details on playbott/android_package_installer#1 (comment).

It might be possible to work around this (try installing the app, then wait 1 minute to see if the installed version changed) but it would be a very bad UX, be more complex, and cause other bugs (like running out of time on the background process because every install takes 1 minute). If anyone subscribed to this thread has Android experience, please take a look at the code - hopefully it's something simple still missing.

from obtainium.

Root and Shizuku installation is now implemented in #1184 🎉

• https://github.com/ImranR98/Obtainium/releases/tag/v0.14.41-beta

from obtainium.

Perhaps if there was a way for the user to set a regular expression per app for which APK to select. That way it's in our hands to control and adjust it when things change.

So Obtainium automatically selects the APK that contains ARM in the title or Free, etc.
If it fails to find that expression, then it simply notifies the user to select as usual.
If it works, it would save time and clicks.

But up to you, I don't feel like this is a pressing issue.

from obtainium.

There's a new APK installer plugin available (44 days old): https://github.com/playbott/android_package_installer Seems to be broken right now though, will keep an eye on it.

Now using this plugin (fixed the error thanks to someone's helpful comments on the issue). Still doesn't do unattended updates, and doesn't work in a background isolate, but it is at least synchronous so it fixes a couple of other issues.

from obtainium.

Just leaving a note that this new plugin uses a permission that is not allowed for Play Store apps, which I guess is part of why Droidify, Neo-Store, etc. are not there. Took down the Play Store listing as it's not as important as having silent updates.

Silent yes, invisible no. The user must always know what the app is installing. For me there must be a download request and an installation request. Then it’s ok.

from obtainium.

Updated the comment with bugfixes (task scheduling and notification related).

from obtainium.

Released: https://github.com/ImranR98/Obtainium/releases/tag/v0.14.0-beta

There is still the problem with install results not being sent back, but I'll open a separate issue for that (I really want to see the purple check on #25 🥲).

There was discussion about unofficial install methods like root and Shizuku. I don't plan on adding those personally but any PRs are welcome.

from obtainium.

@zsolt-donca

1. In Obtainium, Click on the desired apps logo
2. Click the pen icon 🖋️
3. Scroll down to the last option "Exempt from Backround update"
4. Toggle that on

from obtainium.

Yes Im aware that theres more than one reason for multiple versions. That was just an example.

from obtainium.

My humble opinion is that now there is no direct solution for Android 11 and lower, why don't we just focus on Android 12 and higher because you can make it install updates silently granted by the system, and when there is another solution for Android 11 and lower we will go for it to satisfy all users, I mean no one is satisfied right now, the least we can do is going with a solution that is very possible for the meantime, and the door remains open for any contributors who can make it work on lower android versions.

from obtainium.

You can use Shizuku, but it seems like there aren't any Shizuku plugins for Flutter yet. At least you can provide root installation for Android 11 and below, unless you don't want to support this use case.

+1. My current phone from 2019 (which I have rooted) is stuck at Android 11, so please support at least root installation.

from obtainium.

@JohnBetaro support for Android 12+ was always the plan. The Flutter plugin we currently use does use the new API but I have not been able to get it to work silently. Even if that worked, Flutter plugins don't seem to work well in background processes so that's another problem.

Thank you very much for the clarification, so I guess we'll be just waiting until you figure out or someone will help.

from obtainium.

I'm not 100% certain, but I think this issue will be fixed once the changes from flutter/flutter#13937 reach Flutter stable.

from obtainium.

You probably already had the new update installed, so obtainium just skipped installation and incremented the version number. The installer plugin hasn't been updated in over a year so I don't see how it could do that.

from obtainium.

Newer versions of Android allow you to silently update apps that you installed, using a normal supported API. Using something like Shizuku or ADB seems like overkill for something like this (and more difficult than the normal API method).

from obtainium.

There's a new APK installer plugin available (44 days old): https://github.com/playbott/android_package_installer
Seems to be broken right now though, will keep an eye on it.

from obtainium.

I dont want to upgrade to A12 so please dont drop A11 support. Id rather it stays the same.

Nothing would change for < A11

from obtainium.

I dont want to upgrade to A12 so please dont drop A11 support. Id rather it stays the same.

My friend no one is dropping A11 we're just talking about a feature that does not even exist, we want to implement it in A12 and this will never affect the app on your side.

from obtainium.

why don't we just focus on Android 12 and higher because you can make it install updates silently granted by the system

It would be a partial solution, but what can be done should be done first.

That's what I'm talking about, we should solve it using what we know rather than leaving everyone with no solution at all, and as I said the door remains open for anyone who can make it work for all of us in the future.

from obtainium.

In fact, Android 11- support was never my intent as Android does not officially have an API, we'd need root or shizuku or something. Would be a separate lower priority issue.

from obtainium.

Is there a reason you don't plan to add support for root?

Not against it, but it's unlikely I'll know how to do it, given that even using the official Android APIs took so long to figure out (and I don't have rooted devices to test with). Wouldn't be a high priority either way but you could open an issue for it - could always get picked up by someone.

so far 2 of my apps that need updates, did not background install yet.

Criteria for an app to be installed silently:

• Only 1 APK available after applying any filters you set (so you don't need to be present to manually pick an APK)
• The app was originally installed or last updated by Obtainium
• Your OS SDK version must be at least 30 (Android 11)
• The app being updated must target an SDK that is, at most, 3 less than your OS

So I'm guessing those apps don't fulfill one or more of these.

Question, how does background update determine which And pick to use (Architecture wise)?

Same as in the foreground, by file name (if "Attempt to filter APKs by CPU architecture if possible" is enabled). If there's more than one APK available after applying all filters then it doesn't install silently.

from obtainium.

@S7venLights I just use .*arm64.* for my regex on most packages.

from obtainium.

@zsolt-donca you already can - there's a toggle at the bottom of the app options.

from obtainium.

For Brave browser what regular expression can one use, I've tried a few: .Bravearm64Universal. Bravearm64Universal.apk .arm64.

Note I also have a regular expression set for releases in Brave: ^Release

Just 64Universal should work for you.

from obtainium.

Thank you, @S7venLights , I swear I went through the same menu but did not find it 😁

from obtainium.

This, Shizuku, is one thing Droidify uses. But I see in my Droidify settings that it isn't using this, rather session installer and still the updates are unattended. So not sure how he does it.

https://github.com/RikkaApps/Shizuku

from obtainium.

The new plugin does work, and updates done while the app is in the foreground will not have a prompt starting from the next version. Unfortunately, trying to update from a background process is causing an error I haven't been able to figure out. I've made a new issue for that on the plugin repo (felipheallef/flutter-app-installer#1), but this is parked until they respond.

from obtainium.

Nice, this is exciting

from obtainium.

Just leaving a note that this new plugin uses a permission that is not allowed for Play Store apps, which I guess is part of why Droidify, Neo-Store, etc. are not there. Took down the Play Store listing as it's not as important as having silent updates.

Out of curiosity, what's that permission?

from obtainium.

Apps like Neostore/Droidi-fy/GrapheneOS App Store, support unattended updates really well, if you want to have a look at their implementation.

Do those have the same limitations as the flutter plugin method above?

from obtainium.

GraoheneOS probably achieves this by being a system app. The other two have been mentioned in this thread 👍

from obtainium.

Those Apps are not Flutter-based as far as I know, so they probably just use the relevant Android API (the old one is PackageInstaller, idk about the new one). I used Flutter because learning Android would've been too big a time commitment, but I guess that comes with consequences 🥲

Either way, the plugin used right now does work, just not in background processes for some reason. Might be a Flutter limitation and not an issue with the plugin itself.

from obtainium.

Ideas for implementation:
Unattended background updates would be great and I'm anticipating users are probably going to be interested in 3 things I can think of:

• Knowing what's been updated in the background.
  Requiring a menu/tab with a log of updates that can be cleared manually or after a specified period. Or a notification every time an apps are updated.

• Knowing what changes were made to apps.
  Requiring a method to quickly view change logs/release notes See #42

and

• People may want the option to only do manual updates to certain apps.
  Requiring a toggle in per app settings and a universal toggle for all apps.

from obtainium.

@S7venLights regarding your suggestions:

• There is already code to notify users about which apps were updated in the background. I'll just uncomment/enable it when (if?) this issue is fixed.
• For the manual update for specific Apps option, you can make a separate issue for that when this one is resolved.

from obtainium.

The new plugin mentioned above has a dealbreaker - see #46. Switching back to the old one; this issue is blocked for now..

from obtainium.

It actually did work for me. With the latest version I got the prompts back but before the update worked just fine as well.

from obtainium.

It worked with 1 or even 2 apps sometimes, but would choke with larger numbers at least for me. May need to eventually look into learning enough to write my own Flutter plugin for this, or waiting for someone else to :(

from obtainium.

I may be mistaken, but I think Protonmail just installed silently. I opened protonmail in Obtanium, clicked download but the android update dialogue never showed. But it has updated 🤔

from obtainium.

Hey I have a question. Im not sure if it falls under the same category but some apps require a user choice (such as package architecture differences). Would it be possible to have Obtanium remember the selection and therefore not ask the user?

from obtainium.

I've Also wondered about this but I don't imagine there's a standardized way across all of Github to tell which architecture the apk is just from the file name hosted on Github. Obtainium would have to download all the APKs to read the architecture and that would be inefficient.

This may actually be a barrier to silent background updates if the plugin is ever updated.

from obtainium.

What I meant was once the user had chosen a package, it will always opt for that same one.

from obtainium.

Packages are not guaranteed to be the same between apps or even between releases, so any method to save these choices would be unreliable. Also the APK selection is not an architecture selection (APKs are often divided by arch, but no always - some apps have different APKs for the play store VS f-droid for nonfree dependencies, etc.).

from obtainium.

DarQ is a flutter app that uses Shizuku.

AppManager installs apps in the background via local ADB (unfortunately not Shizuku and doesn't auto detect port); the prompt includes version number/name of the old and new version, as well as a list of added/removed activities and checks for trackers. The app provides a large amount of other functionality as well, though I personally only use it for background installs.

Edit: AppManager also has some method to initiate installs via intent using a secret token rather than opening the apk with it. This would be nice as an option as well.

from obtainium.

Appmanager is a great project, im[]agine it also had obtainium features

from obtainium.

I think firstly his focus in this app is security and root would undermine that, however, as an optional feature maybe it isn't a concern.
Also read two messages up.

But also, this app is built with flutter plugins and implementation would depend on if those plugins exist.

from obtainium.

I have read the overkill part. I was only offering my perspective as another user of this app. To me, convenience takes priority. But I also recognize that not everyone would think the same. Thus I suggested a toggle.

I'm not an app developer myself, so I apologize if I happened to have asked for too much.

from obtainium.

Yeah of course, you are free to post ideas/desires here, that's the beauty of FOSS. I'm not a dev either, I just realised my message may read like I was 😅
I've just been following this app for a, while and I gave you some info I thought may apply.

from obtainium.

The UPDATE_PACKAGES_WITHOUT_USER_ACTION permission has been mentioned before. My understanding is that this would still require a user to initiate an update, but does not prompt the user to confirm the update after the apk is downloaded (so long as the installing app has been used to update the apk previously.)

Aurora Store uses this permission so once I choose an app to update, it downloads the apk and installs without any further user interaction.

Is this something Obtainium could implement for the time being?

More info

from obtainium.

You have to consider users lower than Android 12 (which I think is the majority, over users using Android 12 and higher). A quick search shows these plugins supporting root installation:

New OS features not being available on older versions is normal, and I don't think it's an app's responsibility to fill in those gaps via unsupported/hacky methods. Also the majority of users may be on Android 11 and lower but I doubt that many are rooted.

Besides, there are a number of other things that depend on the installer plugin (see #99, #111, #459) so any potential root-based installer plugin would have to behave similarly to the non-root version (in terms of the API and also things like a/synchronous install, reporting results, etc.) so they can be used interchangeably (otherwise we'd have to have a lot of extra code to deal with each plugin separately).

from obtainium.

why don't we just focus on Android 12 and higher because you can make it install updates silently granted by the system

It would be a partial solution, but what can be done should be done first.

from obtainium.

I dont want to upgrade to A12 so please dont drop A11 support. Id rather it stays the same.

from obtainium.

You can use Shizuku, but it seems like there aren't any Shizuku plugins for Flutter yet. At least you can provide root installation for Android 11 and below, unless you don't want to support this use case.

+1. My current phone from 2019 (which I have rooted) is stuck at Android 11, so please support at least root installation.

I also have root access so if that is required for A11 to have silent updates, Im good!

from obtainium.

Perhaps if there was a way for the user to set a regular expression per app for which APK to select. That way it's in our hands to control and adjust it when things change.

So Obtainium automatically selects the APK that contains ARM in the title or Free, etc.
If it fails to find that expression, then it simply notifies the user to select as usual.
If it works, it would save time and clicks.

But up to you, I don't feel like this is a pressing issue.

This would be fantastic. I have to remember every app whether the last time I updated, if it was an arm, or arm_v8, etc. My only complaint really, other than some version issue with Signal number.

from obtainium.

This would be fantastic. I have to remember every app whether the last time I updated, if it was an arm, or arm_v8, etc. My only complaint really, other than some version issue with Signal number.

Already a feature.

from obtainium.

Hi,

I'm here again to talk about the Android 12+ API, I strongly suggest you add it rather than leaving all the users without any solution, when you or a contributor find a way to solve the problem on android 11- devices that will be wonderful, but for now I think we should focus on what's easy to do and will solve the problem for a huge number of people (you included because you use GrapheneOS).

from obtainium.

@JohnBetaro support for Android 12+ was always the plan. The Flutter plugin we currently use does use the new API but I have not been able to get it to work silently. Even if that worked, Flutter plugins don't seem to work well in background processes so that's another problem.

from obtainium.

Looks like the plugin doesn't work due to a null pointer exception because the activity variable on the Kotlin side is null when the app is in the background. Not sure if it's possible to work around this - search didn't turn up anything.

from obtainium.

Nice work, keep it up! Foreground silent install has been working well so far

from obtainium.

awesome, can only confirm it works on my end

from obtainium.

Updated the links in the comment above - fixed a bug where the update checking task would only run once (instead of every N hours)

from obtainium.

So excited to test!

from obtainium.

Is there a reason you don't plan to add support for root?

from obtainium.

The idea that started this app was a more secure way to install apps, so I guess root is not a priority for Imrans spare time

from obtainium.

I was just coming to say though that so far 2 of my apps that need updates, did not background install yet. Used on the zip version you shared.

I've just installed the latest version.
Will test.
Congrads on your milestone though! 😅

Question, how does background update determine which And pick to use (Architecture wise)?

from obtainium.

• Your OS SDK version must be at least 30 (Android 11)

Android 11? You mean Android 12 (which you even mentioned in the first comment)?

from obtainium.

Okay thanks, any guide you can link to, to use regular expressions to filter APKs?
Also any way to globally toggle 'Attempt to Filter APK by Architecture' and choose a preferred architecture?

from obtainium.

For Brave browser what regular expression can one use, I've tried a few:
.Bravearm64Universal.
Bravearm64Universal.apk
.arm64.

Note I also have a regular expression set for releases in Brave: ^Release

from obtainium.

Are there any plans to make silent background update configurable on the individual application level? The reason I'm asking is that while generally I welcome silent background updates for most apps, I would like to still manually update some of my apps, such as Immich, where they sometimes break compatibility on new releases between server and mobile client (they are still in very active development and thus can afford it).

from obtainium.

• Your OS SDK version must be at least 30 (Android 11)

Android 11? You mean Android 12 (which you even mentioned in the first comment)?

You're right. Not sure how I ended up thinking it was SDK 30. Will be corrected soon.

from obtainium.

So happy this feature is here, well done again Imran 🙌

from obtainium.

@ImranR98 I'm sorry but I can't find it. Can you be more specific?

from obtainium.

I'm not why, but I've not been getting BG updates for a while now.
The update check task works but nothing is installing in the background, I have to manually download.
Also if I manually Download Obtainium updates and minimize the app, I get the 'Obtainium must be open to install updates' notification.

Not sure if it's related but I do get a consistent error from Collabora Office (logs shared below). Even though I set it to exempt from background updates and auto-select highest version and No version Detection. With these settings or default settings, it always says: 'No App was found with that ID or Name'

additionally the app FFShare always gives an error on install: Cannot install an older version of an App: [com.caydey.ffshare]

These may be separate issues but I thought I'd post here first before opening new issues.

Logs:
2023-09-14 10:03:12.148: info: Cleared 6 logs (before = 2023-09-07 10:03:11.900054, after = null)

2023-09-14 10:03:16.864: info: BG update task 666: Started (71).

2023-09-14 10:03:20.532: info: BG update task 666: Got error on checking for com.collabora.libreoffice 'No App was found with that ID or Name'.

2023-09-14 10:03:20.533: info: BG update task 666: Will continue in 1 seconds (with com.collabora.libreoffice moved to the end of the line).

2023-09-14 10:10:31.525: info: BG update task 667: Started (71).

2023-09-14 10:22:15.884: info: BG update task 667: Got error on checking for com.collabora.libreoffice 'No App was found with that ID or Name'.

2023-09-14 10:22:15.884: info: BG update task 667: Will continue in 4 seconds (with com.collabora.libreoffice moved to the end of the line).

2023-09-14 10:22:21.225: info: Cleared 7 logs (before = 2023-09-07 10:22:20.956947, after = null)

2023-09-14 10:22:26.007: info: BG update task 668: Started (1).

2023-09-14 10:22:27.832: info: BG update task 668: Got error on checking for com.collabora.libreoffice 'No App was found with that ID or Name'.

2023-09-14 10:22:27.832: info: BG update task 668: Will continue in 9 seconds (with com.collabora.libreoffice moved to the end of the line).

2023-09-14 10:22:41.935: info: BG update task 669: Started (1).

2023-09-14 10:22:45.583: info: BG update task 669: Got error on checking for com.collabora.libreoffice 'No App was found with that ID or Name'.

from obtainium.

@S7venLights could you open another issue

from obtainium.