Skip to content
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

Better version detection #946

Closed
ghost opened this issue Sep 30, 2023 · 38 comments
Closed

Better version detection #946

ghost opened this issue Sep 30, 2023 · 38 comments
Labels
enhancement New feature or request

Comments

@ghost
Copy link

ghost commented Sep 30, 2023

Hi, can I ask why Obtainium does not detect the version very well for apps that do not have a standard format?

This will cause some issues especially when it thinks that the app is updated but the same version was installed as mentioned in #941, can't it just extract the string from the system and compare it to the one indicated on the site?

I know I'm missing something so a brief explanation would be very helpful so I can understand the mechanism.

Thank you.

@ghost ghost added bug Something isn't working to check Issue has not been reviewed labels Sep 30, 2023
@ImranR98
Copy link
Owner

ImranR98 commented Sep 30, 2023

can't it just extract the string from the system and compare it to the one indicated on the site?

That's where the problem is - the string that comes from the system is the real version string, while the string that comes from GitHub is just the Git tag for that release (for other sources it is similar - a string extracted from somewhere that uniquely identifies a release but isn't necessarily the exact version string for that release). Most developers use version strings as Git tags which is great, but some don't. Some do, but add extra info to the Git tag.

For example, you could have any of these cases among others:

  1. App version 0.14.21 but source says v0.14.21-beta (Obtainium)
  2. App version 2.12.8-2+free but source says 2.12.8-2 (Cheogram)
  3. App version 102.2.1-Release (12.5.6) (really, that whole thing is the OS-reported "version") but source says nothing - no version string is provided by this HTML source so a URL hash is used instead as the release identifier (Tor)
  4. App version 1 but source says v10 (Quotable as described in this comment)

So there is no guarantee that the OS-provided "real" version will be in any way comparable to the source-provided "version" which really just needs to uniquely identify a release in order to enable update notifications - it doesn't need to be a real version string.

In most cases, where the strings seem to both conform to some standard format, like x.y.z or x.y, we can make the comparison - and this is when version detection is able to work. In some cases Obtainium can strip off extra parts from the source string if it would result in a standard version (like how v and -beta are removed from Obtainium's v0.14.21-beta), then it can make the comparison. We never try to strip parts off the "real" version, so in the case of Cheogram above, the versions could not be resolved to a standard format.

This is how the various "standard" versions are generated: https://github.com/ImranR98/Obtainium/blob/main/lib/providers/apps_provider.dart#L64
It's always possible to expand this to add more support but we'd need to be careful (see #136 where there was a lot of trial and error figuring this out). For example if an app reports 1.2 but the source says 1.2-4, should we strip off the number 4 and say the two are the same so no update? Right now, that wouldn't happen since we are only allowed to remove specific words and prefixes.

So in general if Obtainium can't resolve the differences between the two strings to a standard format, it disables version detection and hopes the user never has to update the app externally (in which case they would probably never notice the difference).

That's important to clarify - version detection is only relevant in 2 situations:

  1. If an app's version changes outside of Obtainium (for example if it gets updated by Google Play)
  2. If an attempt to silently update the app in the background fails

In those cases, version detection will allow Obtainium to detect that the app's real OS version has changed and update it's internal records accordingly, without generating a false update notification.

Note: For some sources, the source-provided string is guaranteed to be identical to the APK's real version string. For those sources, we skip all this version detection logic and just do a simple comparison. By default, all sources use the version detection logic, and "naive" version detection is enabled on a per-source basis (this means there may be some sources which don't use it right now, but could).

I'm not sure why you mentioned #941 though, I don't think version detection makes any difference there.

@ImranR98 ImranR98 added needs follow up Further information is requested and removed bug Something isn't working to check Issue has not been reviewed labels Sep 30, 2023
@ImranR98
Copy link
Owner

Feel free to re-open if needed.

@ImranR98 ImranR98 closed this as not planned Won't fix, can't repro, duplicate, stale Sep 30, 2023
@ImranR98 ImranR98 removed the needs follow up Further information is requested label Sep 30, 2023
@ghost
Copy link
Author

ghost commented Sep 30, 2023

I acknowledge the GitHub version detection problems that's why I change the version name for some apps that I compile with GitHub Actions, an example would be my fork of Signal, also KeePassDX when he adds "beta" attached directly to the number.

But this rule of removing some suffixes and prefixes can be skipped entirely and just compare the strings from the system and the sites as they are, because they keep the version name as it is in the app, not like apps from GitHub.

Examples:

APKPure Aptoide Uptodown
Screenshot 2023-09-30 140041~2 Screenshot 2023-09-30 140217~2 Screenshot 2023-09-30 135915~2

I hope you'll make some changes that will make Obtainium compare them direcly without any changes and keep your method only for specific sites like GitHub.

@ghost
Copy link
Author

ghost commented Sep 30, 2023

I hope you'll see this since I can't reopen the issue, but I will open a new one if I did not get a response.

@ImranR98 ImranR98 reopened this Sep 30, 2023
@ImranR98 ImranR98 added the enhancement New feature or request label Sep 30, 2023
@ImranR98
Copy link
Owner

Are you confident this is true for all APKPure, Aptoide, and Uptodown apps? It is for the ones I checked, just making sure.

@ImranR98
Copy link
Owner

Also I think I get how this relates to #941 now. Wouldn't fix the issue but would make sure the update would be retried later.

@ghost
Copy link
Author

ghost commented Sep 30, 2023

Are you confident this is true for all APKPure, Aptoide, and Uptodown apps? It is for the ones I checked, just making sure.

No, I just assumed that by checking many apps, I see no reason why wouldn't they use the real version name, since they are only hosting them.

At least we can try and see :)

ImranR98 added a commit that referenced this issue Sep 30, 2023
"Naive" version detection for some Sources (#946)
@ImranR98
Copy link
Owner

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

I'll update the comment above with this info so I can link to to explain version detection it in the future.

@ghost
Copy link
Author

ghost commented Sep 30, 2023

Thank you so much, that was insanely fast.

I don't want to open another issue because my next suggestion is related to this one.

If you can just add a toggle for "use tag as version" in the version detection section and make Obtainium use the tag as provided by GitHub and GitLab without any changes and compare it directly to the version name provided by the system.

Situations where this option will be useful:
KeePassDX (GitHub)

Addy.io (GitLab)

And I can think of many scenarios where this option will be very useful and the old method will not detect the version very well.

@ImranR98 ImranR98 reopened this Sep 30, 2023
@ghost

This comment was marked as resolved.

@silverwings15
Copy link

silverwings15 commented Oct 9, 2023

having trouble with this one myself. the link i used is https://gitlab.com/AuroraOSS/AuroraStore/-/releases

image

@ghost
Copy link
Author

ghost commented Oct 9, 2023

@silverwings15 I don't think this is related the issue that we are trying to solve, you better open a dedicated one for it.

@silverwings15
Copy link

oh i see. in that case i'll do so right away

@ghost
Copy link
Author

ghost commented Oct 9, 2023

@silverwings15 You don't have to, already known issue that couldn't be solved in #697, but the solution I'm personally using is getting it from Uptodown or F-Droid.

So please don't open a new issue or close it if you did already.

@silverwings15
Copy link

silverwings15 commented Oct 9, 2023

whoops, saw this a little too late. let me go ahead and close it

will adopt your solution as well, tyvm!

@M00NJ
Copy link

M00NJ commented Oct 9, 2023

I'm also experiencing issues with obtainium not being able to detect the latest version of apps from GitHub and IzzyOnDroid (See screenshots, I manually installed the actual latest versions). In the case of ConnectYou I checked if the version string is the same as the tag on GitHub and it is, so I don't know where this issue is comming from... :/
Screenshot_20231009-135936
Screenshot_20231009-135947

@ghost
Copy link
Author

ghost commented Oct 9, 2023

@M00NJ
As for Connect You I am 99% sure it is from the developer side, because the latest version is not showing up for some reason.

As for InnerTube why don't you just get it from the official GitHub repo because that's exactly where izzyondroid is getting his apps from, why use Obtainium to get app from a repository that already takes its apps from GitHub? It is exactly the same app. And you can ask the maintainer if you want.

@M00NJ
Copy link

M00NJ commented Oct 9, 2023

@JohnBetaro
Connect You should be detected properly. The version was increased like in all the other releases. See: you-apps/ConnectYou@d1d1b05

InnerTune hast two flavors. The FOSS flavor is only available on Izzy and F-Droid. The one on GitHub has trackers and uses geolocation see: z-huang/InnerTune#935

@ghost
Copy link
Author

ghost commented Oct 10, 2023

@M00NJ

Maybe the developer will explain the situation of Connect You because I don't know what happened exactly there.

But for InnerTune, as I said you can get it from GitHub and there is a FOSS variant in the releases you can see it very clearly here, and I assure you if you can get it from GitHub then Izzyondroid is not needed at all, you can ask the maintainer himself and he will tell you that he gets his apps directly from GitHub, he doesn't build them at all. It is the same app and you can confirm it youserlf by verifying the signature of each one from GitHub and Izzy (I just did now it to confirm).

See how Izzy works

@M00NJ
Copy link

M00NJ commented Oct 10, 2023

Thanks for the InnerTune link. I missed that the FOSS flavor is available on github as well now. I'll switch to that in Obtainium. As for ConnectYou, I'm one of the devs that works on it. I didn't create this release, but checked and everything looks right. I will ask to handle the next release. Let's see if Obtainium detects it when it's out. If not we'll have to take a closer look at this.

@unbranched
Copy link
Contributor

unbranched commented Oct 17, 2023

I add (if not clear from above) and example of productFlavors not detected:
KeepassDX has this parameter, my installed version has the ".free" suffix so Obtainium doesn't detect it.

@ghost
Copy link
Author

ghost commented Oct 17, 2023

@unbranched Obtainium Is not meant to detect flavors, this will be very hard and complex task I guess, because every developer has its own way to rename and publish apps.

Some of them publish all the flavors, some of them don't, some of them change the naming pattern, some of them preserve the original names, ...

I don't know why do you want this feature, maybe you can give some examples to understand what problems can this one solve.

@unbranched
Copy link
Contributor

unbranched commented Oct 17, 2023

@JohnBetaro it could maybe added a new optional parameter in the single App's page (in this example KeepassDX) to specify the versionName that needs to be checked in installed apps.

I'm asking this feature because Obtainium currently doesn't find KeepassDX as installed.

@ghost
Copy link
Author

ghost commented Oct 17, 2023

I'm asking this feature because Obtainium currently doesn't find KeepassDX as installed.

I have no problems on my end, I tried KeePassDX and everything is working perfectly, Obtainium is supposed to detect it as installed normally, I don't know what is happening on your side.

@unbranched
Copy link
Contributor

unbranched commented Oct 17, 2023

I have no problems on my end, I tried KeePassDX and everything is working perfectly, Obtainium is supposed to detect it as installed normally, I don't know what is happening on your side.

Where did you install it from? Play Store, F-Droid or Github?

@ghost
Copy link
Author

ghost commented Oct 17, 2023

Where did you install it from? Play Store, F-Droid or Github?

From GitHub of course, I use Obtainium.

@unbranched
Copy link
Contributor

@JohnBetaro this is so strange. Retried to add it and has the same problem, look at these two images. What you can't see on the second one is only the enabled "Attempt to filter APKs by CPU..."

https://i.postimg.cc/4N3Gwv2t/app-page.png

https://i.postimg.cc/s25C1T1F/app-settings.png

I added it just by using the url https://github.com/Kunzisoft/KeePassDX/releases

@ghost
Copy link
Author

ghost commented Oct 17, 2023

@unbranched Did you click Install ? What happens when you download it and then install it ?

@ImranR98
Copy link
Owner

@unbranched could you also see if the package ID of your existing install matches the one found by Obtainium? You might be able to see it in your OS settings under Apps (depends on the OS)?

@ImranR98
Copy link
Owner

ImranR98 commented Oct 17, 2023

Just saw your earlier comment. If your F-Droid version of the app has the .free suffix in the package ID, then it is a totally separate app as far as the OS is concerned (there is no concept of "flavours" as far as I know). You could even install both side by side. So Obtainium not detecting it is totally expected.

@unbranched
Copy link
Contributor

unbranched commented Oct 18, 2023

Just saw your earlier comment. If your F-Droid version of the app has the .free suffix in the package ID, then it is a totally separate app as far as the OS is concerned (there is no concept of "flavours" as far as I know). You could even install both side by side. So Obtainium not detecting it is totally expected.

KeepassDX github version has the .free suffix and that's the version I have installed (F-Droid version has .libre I guess). Obtainium is searching for updates on com.kunzisoft.keepass, so that's why it doesn't find it.
For this reason I'm asking if I can make it search com.kunzisoft.keepass.free in some way.

EDIT: problem solved, looks like the only solution was to delete KeepassDX and make it install by Obtainium. Now it correctly searches com.kunzisoft.keepass.free .

@henosch
Copy link

henosch commented Jan 10, 2024

Screenshot_20240110-151225.png

@ImranR98
Copy link
Owner

@ImranR98
Copy link
Owner

ImranR98 commented Apr 9, 2024

@The-Kyber not sure I understand, could you walk through an example?

Remember the goal is to reliably detect changes made to an app outside of Obtainium. Let's say Obtainium thinks version 0.1 of an app is installed. If you install version 0.2 using the Play Store, Obtainium should detect that and switch it's own internal record to 0.2 as well.

@ImranR98
Copy link
Owner

ImranR98 commented Apr 9, 2024

I don't see the problem you're trying to solve. If we're only concerned about update tracking within Obtainium, we don't need to deal with the OS version at all. We don't even need a version string of any kind - any release-specific ID will do, like timestamps, url hashes, etc. (we already use those kinds of identifiers in some cases).

@ImranR98 ImranR98 closed this as completed Apr 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants
@silverwings15 @ImranR98 @unbranched @henosch @M00NJ and others