[Bug] ApkTrack 2.1.1b, 2.1.1c and 2.1.1d as built and distributed by F-Droid crash when entering ApkTrack's settings #106
Comments
Olf0
changed the title
|
Thanks for letting me know. The 2.1.1b is a beta APK and shouldn't have been posted to F-Droid, it's my mistake for tagging the release. I have received several crash reports through the app, so I'll look into it shortly. |
|
O.K. for me (now that I know why). Still, as the F-Droid client and ApkTrack itself believe v2.1.1b is an upgrade over v2.1.1 and offer it as such, while it is absolutely not obvious to users that it is not (its release is half a year never and nothing denotes it being a beta version in these two apps): Isn't it possible to delete v2.1.1b on f-droid or mark it as a beta version, in order to prevent others from installing v2.1.1b due to believing it being a stable release (... just to comprehend it is not, then downgrading, and finally experiencing an extremely useful and nice app ... or giving up meanwhile). |
|
ApkTrack believes it's an update because that's what F-Droid reports. I don't maintain the F-Droid build so I can't do anything but fix the bug ASAP and make sure they release the fix. |
Sure, that was obvious.
... that the F-Droidians are maintaining their repository entries (both, description and the actual APKs) completely independently of the original author of the software. Side note: Fixing this on f-droid would also alleviate the need to publish a new non-beta version "ASAP", as ApkTrack 2.1.1 is basically working fine. |
|
Filed as F-Droid metadata issue 862. |
|
@JusticeRage Can you remove the tag until 2.1.1b is ready? Otherwise it will either be picked up by fdroid in the next update cycle again or we'd need to disable automatic updates for now. (which is a maintenance burden as you can imagine). |
|
The tag is correct: version 2.1.1b IS version 2.1.1b... But as it's tagging a commit on the beta branch, I didn't expect that it would be picked up by F-Droid. Is there a way to only use code for the master branch, or at least make beta branch APKs opt-in only? @Olf0: I am unable to reproduce this issue on any device I use. I made a tentative fix, would you be able to test it and let me know if the issues are still present? Here is the new APK for the fix: https://apktrack.kwiatkowski.fr/apk/ApkTrack_test.apk |
|
@JusticeRage , thanks for creating a test version of ApkTrack. |
|
Ah, you're using versions signed by F-Droid I fear... I can only sign with my own key, obviously. You can either uninstall their version to install mine then, or we'll wait for someone else who has the problem to try this APK. |
|
Sorry, could have thought about that, too. But surprisingly, after uninstalling the f-droid version and then trying again: Same result. Well it is late, I have one more idea, what to check, but will postpone that to tomorrow. |
|
Is there a particular error message for the failed install? If you can check the logcat, it may contain relevant information. |
|
Tested ApkTrack_2.1.1a.apk (2017-08-27) from your site: Installs fine. "Particular error message" is (see screenshot) ... not very particular. ;/ Capturing logs, maybe tomorrow. |
|
I've found the issue with an older device I have. This is linked to the signature scheme used to generate the APK (v1 or v2). Long story short, it seems that only recent devices support v2. I've updated the APK at the same URL, please give it a try when you can! |
|
The new test version is installing fine and working well, including entering the settings. :)) Still leaving this issue open, as ...
|
|
Thanks for your feedback. I will publish a new release with this code immediately. |
|
@JusticeRage There is another update mode in fdroid which looks at the versioncode in the Another option would be to tag the beta releases with something like vx.y.z-beta. These can be expluded from fdroid then as well. |
|
Then I would rather go with the -beta naming scheme! |
|
@JusticeRage, note that the test version (2017-09-03) does not display all installed apps! E.g., FBReader and all its plugins (except for the third party TTS+ plugin) are missing from ApkTrack's list of installed apps. Searching for them also does not cause ApkTrack to find them. Another, much more minor flaw in ApkTrack 2.1.1b and the test version: |
|
The Guardian Project source has been removed. As for missing apps, this is the first time I've heard of it. Do you use Greenify on your device? |
|
[Guardian Project]: O.K., I have seen their Repository being unreliable (with the F-Droid client) in the past, too. [Greenify] No, never heard of it before. |
|
Doze and Greenify are apps that "hibernate" inactive apps to save battery. When ApkTrack is put to sleep this way, it can't receive intents indicating that an app has been installed / upgraded. |
Yes, this can be specified as a regex, see the last paragraph under So for now we'll update to 2.1.1c for the bug fix, then for the next beta version you'll tag them as -beta? |
Hmm, doesn't that imply, that one must always have ApkTrack running in the background for it being able to receive such "app installed / upgraded" intents? |
|
@Bubu Agreed: 2.1.1c should be released as it fixes the current bug. |
|
Okay, I'll make the change later. |
|
And APKtrack_test.apk (2017-09-04 22:51) successfully finds all installed APKs (in contrast to the test version before) on my device, when scanning for them at APKTrack's first run. |
|
I can assure you that no code has been added to that effect... |
|
O.K., let's assume I somehow accidentally interrupted ApkTrack's scan at first run, once. |
|
This is crazy, I'm still getting crash reports despite the proguard fix... This is definitely something happening with F-Droid builds, as mine work fine (with the exact same source). Obviously, I have no way of investigating or reproducing the bug as I can't interact with F-Droid's build system. Here is a sample stacktrace if anyone wants to have a go at this.
|
|
it crashes for me too... investigating. |
|
I can trigger the crash as well on my device using the F-Droid build of the app. I've compared the decompiled APKs side by side and I don't think anything is missing. |
|
@JusticeRage I can reproduce the weird apk when using a local copy of the buildserver vm. I also could reproduce the issue on my very first local build today. But not on any subsequent ones. This is all very weird... but if I manually login to the buildserver which just build a non-working apk and trigger the build again I get a working apk. (Comparing the non-working with the working version after running them through apktool decode, there seem to be quite a few things missing and different in the broken one.) But I have absolutely no idea why other than that it appears to be an issue on the first build in a clean environment. A gradle clean is definitely not clean enough... Let me try again after purging ~/.gradle. Maybe that gives a reproducable result. |
|
Jup, got it... I just reproduced this from a fresh repo copy without f-droid. When deleting the gradle cache No idea why this is happening but I think you should be able to reproduce this now? (So this is happening for fdroid because it always starts from an empty gradle cache) Indeed running |
|
Hey @Bubu , thanks for this analysis so far! I still wonder, why ApkTrack 2.1.1 (no "a", "b", "c" or "d" suffix) from F-Droid does not show this issue. Was there a significant change in the compile environment of F-Droid between its build date (2017-01-22) and v2.1.1b (2017-08-30)? Side note: Sorry, I noticed the size difference of the ApkTrack 2.1.1c APK at F-Droid compared to the direct download from @JusticeRage once, but forgot to mention it here. |
|
@Olf0 I would guess something changed on apktrack's side between those version, but I'm not sure. |
|
@Bubu , while I absolutely agree that the root cause of this ought to be determined and a proper fix for this issue developed thereafter, I disagree with your "rather": As all recent ApkTrack releases (starting with v2.1.1b of 2017-08-30) on F-Droid are broken, uploading a working version to F-Droid soon (so it gets picked up in F-Droid's next update cycle) would alleviate the frustration among ApkTrack's users. |
|
@Olf0 I have disabled 2.1.1b/c/d from f-droid. they will disappear in the next update cycle and will not be recommended for new users. You should be able to downgrade to the last working version. As for a new version I'm not sure, we could rebuild them with this workaround. But they were originally intended as beta version so this seems a bit overkill. We should probably fix the root cause for the next proper release. |
|
@Bubu I confirm your observation: deleting the .gradle folder triggers the faulty build, and building twice solved the issue. |
|
@Bubu , thanks. |
Olf0
changed the title
Olf0
changed the title
|
@Bubu ,
this did not work for this cycle (just pulled updated repo metadata), somehow.
Oh, I do that each time immediately after testing a broken one. ;\ |
|
@Bubu: After getting a reply from @CommonsWare, I think the issue has been traced back to ProGuard. I have disabled it entirely in the latest commit of the beta branch and it seems to solve the issue on my device (removing |
|
@JusticeRage current beta branch fixes the problem for me too! 👍 (Just for the record, the resulting apk is now 2.4 MB in size. Proguard does sound rather a bit like black magic at this point ;-)) |
|
@Bubu ,
You mean, checked out from the current beta branch compiled in an "F-Droid VM" build environment?
After reading about ProGuard: Isn't that expected, as ProGuard is supposed to make the resulting APK smaller (2,4 MB to 1,5 MB for ApkTrack 2.1.1x, and 1,3 MB for the broken versions)? |
|
Oh, ProGuard's original online manual is old (2011) and outdated (covers v4.7), so the only hints I found was Customize which code to keep (and the subsequent sections Customize which resources to keep and Troubleshoot resource shrinking) on aforementioned web page, which I believe you are already aware of. And there still is no proper explanation for the strange "build twice to produce a working APK" behaviour (when compiling the first time), right? |
|
I have tagged a new release, hopefully this will all be behind us soon. As for the bug's cause, I'll just quote the SO reply from @CommonsWare:
|
Unfortunately that did not work for the last cycle (as already reported, but maybe the changes came in too late) and this cycle.
... which was not picked up this cycle either, but hopefully the next one. |
|
Thank you, @JusticeRage and @Bubu, for travelling this long journey with several detours together, which has almost come to an end with the release of ApkTrack 2.1.2 on F-Droid, today. The only remaining point is, that ...
... still does not work, after (at least) three "cycles" at F-Droid. |
|
I see only 2.1.1 and 2.1.2 on my devices. Just updated the index. Looking at the fdroid wiki they shouldn't be there for yoyu anymore. Not sure what's going on, can you open an issue at the f-droid bug tracker? Client would be the correct location I think. |
|
Oh, this is confusing: I think I have to take a look at F-Droid's main repository metadata XML file first, in order to alleviate this confusion a bit, before being able to write a issue report, which is not equally confusing. Ah, but when doing the straight forward test to install v2.1.1b/c/d in the F-Droid client, their download fails immediately. |
ApkTrack 2.1.1b (release date 2017-08-30 on f-droid) crashes under AOSP 4.1.2 when entering ApkTrack's settings.
ApkTrack 2.1.1 (release date 2017-01-22 on f-droid) is working fine, hence I reverted to it.
If logs etc. are helpful, please let me know.
The text was updated successfully, but these errors were encountered: