[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

[Olf0]

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.

[JusticeRage]

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.

[Olf0]

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).

[JusticeRage]

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.

[Olf0]

ApkTrack believes it's an update because that's what F-Droid reports.

Sure, that was obvious. What I did not know, was ...

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.

... that the F-Droidians are maintaining their repository entries (both, description and the actual APKs) completely independently of the original author of the software. Thanks for pointing this out. So I will try to report this and issue #111 to them, using these issues descriptions and dialogue with you as references.

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.

[Olf0]

Filed as F-Droid metadata issue 862.

[Bubu]

@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).

[JusticeRage]

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? My current plan is to publish version 2.1.1c fixing this bug shortly (hopefully tomorrow).

@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

[Olf0]

@JusticeRage , thanks for creating a test version of ApkTrack. When installing, it is correctly detected as an update over the installed ApkTrack 2.1.1, but then fails to install, unfortunately. So I am reverting to v2.1.1 once more. ;)

[JusticeRage]

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.

[Olf0]

Sorry, could have thought about that, too.

But surprisingly, after uninstalling the f-droid version and then trying again: Same result. Then I checked that the installation of non-market apps was allowed (it was), rebooted and tried again: Still fails to install, after asking for the access rights.

Well it is late, I have one more idea, what to check, but will postpone that to tomorrow.

[JusticeRage]

Is there a particular error message for the failed install? If you can check the logcat, it may contain relevant information.

[Olf0]

Tested ApkTrack_2.1.1a.apk (2017-08-27) from your site: Installs fine. And is working well, including entering the settings! So it is definitely not an issue with your signing keys / signature.

"Particular error message" is (see screenshot) ... not very particular. ;/

Capturing logs, maybe tomorrow.

[JusticeRage]

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!

[Olf0]

The new test version is installing fine and working well, including entering the settings. :)) Thank you!

Still leaving this issue open, as ...

• the beta status of ApkTrack 2.1.1b on F-Droid is not finally resolved, yet.

• no new version with these bug fixes is publicly available yet.

[JusticeRage]

Thanks for your feedback. I will publish a new release with this code immediately.

[Bubu]

@JusticeRage There is another update mode in fdroid which looks at the versioncode in the build.gradle file in master branch. But this mode doesn't care about tags anymore. Would that fit your workflow?

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.

[JusticeRage]

Then I would rather go with the -beta naming scheme! Does -beta1, -beta2, etc. tags get excluded as well, or should I use 2.1.1x-beta instead ?

[Olf0]

@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. ApkTrack 2.1.1 and other apps (e.g. Application Info, Aptoide client) do display all installed apps.

Another, much more minor flaw in ApkTrack 2.1.1b and the test version: Apps from the Guardian Project are not detected anymore, and the Guardian Project is also not available for manual selection anymore (when an app is installed from there). This worked well in ApkTrack 2.1.1 But exactly the same automatic detection mechanism works fine in all tested versions (2.1.1, 2.1.1b, test version) for Öffi!

[JusticeRage]

The Guardian Project source has been removed. I have discovered that their website is not up to date and does not provide reliable links to the latest APK, or even the latest APK for that matter. For this readon, I decided to drop it in 2.1.1b.

As for missing apps, this is the first time I've heard of it. Do you use Greenify on your device?

[Olf0]

[Guardian Project]: O.K., I have seen their Repository being unreliable (with the F-Droid client) in the past, too. But fetching their repository metadata is working well again (but only in the F-Droid client, see issue #112) in the last couple of weeks.

[Greenify] No, never heard of it before.

[JusticeRage]

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.

[Bubu]

@JusticeRage:

Does -beta1, -beta2, etc. tags get excluded as well, or should I use 2.1.1x-beta instead ?

Yes, this can be specified as a regex, see the last paragraph under Tags here: https://f-droid.org/docs/Build_Metadata_Reference/#Update-Check-Mode

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? I'll change the fdroid update check then accordingly.

[Olf0]

@JusticeRage,

[...] When ApkTrack is put to sleep this way, it can't receive intents indicating that an app has been installed / upgraded.

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? Well, I don't, I start ApkTrack on demand (disabled its autostart, which is default for Android apps under AlienDalvik). That's why I asked for a possibility for a manually triggered rescan (or an automatic rescan on startup; the last test version seems to be really fast at this, when first run after its installation) in issue #107. As this topic belongs there, continuing there ...

[JusticeRage]

@Bubu Agreed: 2.1.1c should be released as it fixes the current bug. For the future, release tags will take the form "X.Y.Z" or "X.Y.Za", "X.Y.Zb", etc. Tags such as "X.Y.Z-betaN" will designate beta releases and should be excluded (unless some users want to opt-in for beta builds, I don't know if F-Droid supports this).

[Bubu]

Okay, I'll make the change later. Beta releases can for now be added manually if someone wants to to that. There are plans to handle this better in the future.

[Bubu]

Here is the regex I ended up with: https://gitlab.com/fdroid/fdroiddata/commit/6803e48cd787fa34f5d4c324bdb1f213dff65987

[JusticeRage]

I would have been okay with ^([0-9]\.)?[0-9]\.[0-9][a-z]?$ but that works for me!

[Olf0]

@JusticeRage , unfortunately the original issue is still present: ApkTrack 2.1.1c crashes on my device, when entering its settings, just as v2.1.1b does (both from f-droid). In contrast to that v2.1.1 (from f-droid), v2.1.1a and the 2017-09-03 test version (both from your web site) do not crash, when entering their settings. So, can you please reopen this issue. And please let me know, if logs would be helpful for you.

[JusticeRage]

That's crazy. The test version I had sent you IS the same as 2.1.1c. I mean, this is the only commit! https://github.com/JusticeRage/ApkTrack/commit/51b794a1d0d80da3b41472a5638e94c51ff989e0 Sure, show me the logs :(

[Olf0]

Logs (taken with aLogcat):

• Crash entering the settings in ApkTrack 2.1.1c (from f-droid): apktrack2.1.1c_crash-entering-settings_alogcat_filtered-apktrack.txt

• O.K. when entering the settings in ApkTrack 2.1.1 (from f-droid): apktrack2.1.1_entering-settings_alogcat_filtered-apktrack.txt

[Olf0]

[Commit 51b794a] Is it so unlikely, that the change in line 70 in <app/src/main/java/fr/kwiatkowski/apktrack/ui/SettingsFragment.java> is causing these crashes?

[JusticeRage]

It is unlikely because it was present in the former test version you installed last time. This was actually the expected fix. I'll look into your log (thanks!), but in the meantime, could you try this new APK? It's basically the exact same code, only built by me and not F-Droid. It's unlikely this is the issue, but I'd like to try anyway to see if it makes any difference.

EDIT : a possibly related thread in which they recommend downgrading the support library. EDIT2 : Ooooh. If my APK works, I'm pretty sure that I've got the definite root cause. F-Droid may be using ProGuard, while I don't. This causes needed classes to be removed from the final APK. I will release 2.1.1d as soon as you confirm that my APK works.

[JusticeRage]

@Bubu I tagged a new release a few days ago, but it doesn't seem like the system has picked it up!

[Bubu]

@JusticeRage The last Checkupdates ran 3 days ago (not sure why ...) https://gitlab.com/fdroid/fdroiddata/commits/master It will pick up the new version on the next run.

(I don't think fdroid is using proguard, but not quite sure)

[Olf0]

Yes, APKtrack_test.apk (2017-09-04 22:51) is working fine, i.e. it does not crash entering its settings on my phone. So the F-Droidians seem to use ProGuard or something similar!

BTW,

Tags such as "X.Y.Z-betaN" will designate beta releases and should be excluded (unless some users want to opt-in for beta builds, I don't know if F-Droid supports this).

Beta releases can for now be added manually if someone wants to to that. There are plans to handle this better in the future.

ah, this explains, why I have seen this so rarely on F-Droid. E.g. Sokoban (the last release on F-Droid: v1.14) and some versions of the F-Droid client were explicitly marked as Betas and hence (correctly) not offered as an update (unless configured otherwise in the F-Droid client settings), even though they were newer than all stable releases (at that time).

[Olf0]

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.

[JusticeRage]

I can assure you that no code has been added to that effect...

[Olf0]

O.K., let's assume I somehow accidentally interrupted ApkTrack's scan at first run, once. It was just a little observation, but not properly tested, anyway. Well, in order not to get side-tracked here, I may retest and open a separate issue for that, if really necessary. Side note: Testing this will be much easier with a Rescan button (see issue #107), someday.

[JusticeRage]

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. I'm getting extremely frustrated over this.

Here is a sample stacktrace if anyone wants to have a go at this.

android.view.InflateException: Binary XML file line #19: Error inflating class PreferenceScreen at android.support.v7.preference.PreferenceInflater.createItem(Unknown Source) at android.support.v7.preference.PreferenceInflater.onCreateItem(Unknown Source) at android.support.v7.preference.PreferenceInflater.createItemFromTag(Unknown Source) at android.support.v7.preference.PreferenceInflater.inflate(Unknown Source) at android.support.v7.preference.PreferenceInflater.inflate(Unknown Source) at android.support.v7.preference.PreferenceManager.inflateFromResource(Unknown Source) at android.support.v7.preference.PreferenceFragmentCompat.addPreferencesFromResource(Unknown Source) at fr.kwiatkowski.apktrack.ui.SettingsFragment.onCreatePreferences(Unknown Source) at android.support.v7.preference.PreferenceFragmentCompat.onCreate(Unknown Source) at fr.kwiatkowski.apktrack.ui.SettingsFragment.onCreate(Unknown Source) at android.support.v4.app.Fragment.performCreate(Unknown Source) at android.support.v4.app.FragmentManagerImpl.moveToState(Unknown Source) at android.support.v4.app.FragmentTransition.addToFirstInLastOut(Unknown Source) at android.support.v4.app.FragmentTransition.calculateFragments(Unknown Source) at android.support.v4.app.FragmentTransition.startTransitions(Unknown Source) at android.support.v4.app.FragmentManagerImpl.executeOpsTogether(Unknown Source) at android.support.v4.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(Unknown Source) at android.support.v4.app.FragmentManagerImpl.execPendingActions(Unknown Source) at android.support.v4.app.FragmentManagerImpl$1.run(Unknown Source) at android.os.Handler.handleCallback(Handler.java:739) at android.os.Handler.dispatchMessage(Handler.java:95) at android.os.Looper.loop(Looper.java:158) at android.app.ActivityThread.main(ActivityThread.java:7225) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1230) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1120) Caused by: java.lang.NoSuchMethodException: [class android.content.Context, interface android.util.AttributeSet] at java.lang.Class.getConstructor(Class.java:528) at java.lang.Class.getConstructor(Class.java:492) ... 26 more java.lang.NoSuchMethodException: [class android.content.Context, interface android.util.AttributeSet] at java.lang.Class.getConstructor(Class.java:528) at java.lang.Class.getConstructor(Class.java:492) at android.support.v7.preference.PreferenceInflater.createItem(Unknown Source) at android.support.v7.preference.PreferenceInflater.onCreateItem(Unknown Source) at android.support.v7.preference.PreferenceInflater.createItemFromTag(Unknown Source) at android.support.v7.preference.PreferenceInflater.inflate(Unknown Source) at android.support.v7.preference.PreferenceInflater.inflate(Unknown Source) at android.support.v7.preference.PreferenceManager.inflateFromResource(Unknown Source) at android.support.v7.preference.PreferenceFragmentCompat.addPreferencesFromResource(Unknown Source) at fr.kwiatkowski.apktrack.ui.SettingsFragment.onCreatePreferences(Unknown Source) at android.support.v7.preference.PreferenceFragmentCompat.onCreate(Unknown Source) at fr.kwiatkowski.apktrack.ui.SettingsFragment.onCreate(Unknown Source) at android.support.v4.app.Fragment.performCreate(Unknown Source) at android.support.v4.app.FragmentManagerImpl.moveToState(Unknown Source) at android.support.v4.app.FragmentTransition.addToFirstInLastOut(Unknown Source) at android.support.v4.app.FragmentTransition.calculateFragments(Unknown Source) at android.support.v4.app.FragmentTransition.startTransitions(Unknown Source) at android.support.v4.app.FragmentManagerImpl.executeOpsTogether(Unknown Source) at android.support.v4.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(Unknown Source) at android.support.v4.app.FragmentManagerImpl.execPendingActions(Unknown Source) at android.support.v4.app.FragmentManagerImpl$1.run(Unknown Source) at android.os.Handler.handleCallback(Handler.java:739) at android.os.Handler.dispatchMessage(Handler.java:95) at android.os.Looper.loop(Looper.java:158) at android.app.ActivityThread.main(ActivityThread.java:7225) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1230) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1120)

[Bubu]

it crashes for me too... investigating.

[JusticeRage]

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. I don't have my signing keys at hand, but I'll checkout the project and generate a brand new APK on a new machine tonight to make sure once more that everything is fine with the source code. EDIT: For now I can already confirm that with the emulator.

[Bubu]

@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.

[Bubu]

Jup, got it... I just reproduced this from a fresh repo copy without f-droid. When deleting the gradle cache ~/.gradle and then running ./gradlew assembleRelease I get an apk file which is just 1.3MB instead of 1.4MB and which crashes on entering settings.

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 ./gradlew assembleRelease a second time from this state does actually recompile some things and finally produces a working apk. Running it a third time it says everything is up-to-date.

[Olf0]

Hey @Bubu , thanks for this analysis so far! Even though the root cause is not determined yet, you now have a workaround (running ./gradlew assembleRelease twice) to compile a working APK, which should be published on F-Droid ASAP, IMHO.

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)? Note that this coincidences which the size reduction of the APKs at F-Droid from 1,5 MB (v2.1.1) to 1,3 MB (all later versions)!

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.

[Bubu]

@Olf0 I would guess something changed on apktrack's side between those version, but I'm not sure. I'd rather get this fixed properly than doing some workaround with building it twice.

[Olf0]

@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.

[Bubu]

@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.

[JusticeRage]

@Bubu I confirm your observation: deleting the .gradle folder triggers the faulty build, and building twice solved the issue. This might be bigger than us. I'm opening a StackOverflow thread to see if anyone has encountered this before.

[Olf0]

@Bubu , thanks. As my main point was, "Please stop distributing a broken ApkTrack APK as current version from F-Droid.", disabling them also achieves that.

[Olf0]

@Bubu ,

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.

this did not work for this cycle (just pulled updated repo metadata), somehow.

You should be able to downgrade to the last working version.

Oh, I do that each time immediately after testing a broken one. ;\