-
Notifications
You must be signed in to change notification settings - Fork 229
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
bug(apkmirror): can't find as many updates with APKUpdater as with 2.x #434
Comments
Was curious to see if it also happens to other apps and the answer is yes. Take a look at Google Play Services for example (haven't seen any update of it via APKUpdater since V2), see https://www.apkmirror.com/apk/google-inc/google-play-services/google-play-services-23-34-14-release/. I can install any of those, so it should appear in APKUpdater as well. I feel like APKUpdater only knows about a few architectures, like v7a en v8a, while I have v9a. V9a is also backwards compatible with v7a and v8a of course, but APKUpdater doesn't seem to take that into account, which is why it thinks the apps aren't compatible with v9a. See here:
private val arch = when {
Build.SUPPORTED_ABIS.contains("x86") -> "x86"
Build.SUPPORTED_ABIS.contains("x86_64") -> "x86"
Build.SUPPORTED_ABIS.contains("armeabi-v7a") -> "arm"
Build.SUPPORTED_ABIS.contains("arm64-v8a") -> "arm"
else -> "arm"
} |
I checked the Maps case and the problem is APKMirror's API. Instead of returning the normal Maps version it returns the Wear Maps version. On 2.x Wear updates were not filtered and that's why you see more of them. I don't think I can fix this. |
For the Oneplus Game, there's indeed an arch matching failure that should be easy to fix |
Here is a debug version with the fix and different package name |
Hmm okay, so I guess this is maybe also the case with some other apps. I just contacted APKMirror and told them about this issue (and linked to this issue on GitHub as well).
That indeed fixed it, but over the past 2-3 days I haven't noticed any other difference; for example, the debug still found as many updates as the release APK, which I find surprising. |
@rumboalla Looking at the current supported parameters for this API call, I'm indeed only seeing the ability to filter out certain release tags (alpha, beta), but not specify the capability (Wear, Auto, ATV, etc.) or anything else. If we were to work on this, what would you like to see added to this API endpoint? Just the ability to specify (or exclude?) a list of capabilities? What about architectures? Anything else? |
Having the choice to specify architectures and capabilities would be nice. |
@archon810 Any updates on this? 🙂 |
Creating an issue for this, see below for context:
To add on top of that: it's quite noticeable how since I use V3, I have way more updates available via the Play Store and way less updates available via APKUpdater V3. I only use APKMirror as source. It seems like the logic differs from V2. The 2.x updates are "correct" yeah, but I can't use it anymore because it's the same package name (and thus gets updated).
Well, the update is gone by now, but I'll let you know when it happens again. Perhaps a screen record will do? Then you have all info too.
Originally posted by @AnonymousWP in #396 (reply in thread)
The text was updated successfully, but these errors were encountered: