handle multiple APKs per repo differing only by signing key

The client database needs to support a single repo that serves multiple copies of the exact same APK, with the only different being the signing key. This is needed to provide a smooth transition to the upstream developer's signing key, away from the fdroid signing key, once an app has been added via the reproducible process.

The basic idea is:

• host both fdroid and upstream APKs in the same repo
• new metadata for "preferred signing key"
• for new installs, then client chooses the APK signed by the preferred key
• for upgrades, the client chooses the APK signed by the key that matches the currently installed APK

@pserwylo Re: the scrum yesterday

mentioned in issue fdroidserver#153

mentioned in issue #831 (closed)

mentioned in issue #844 (closed)

@eighthave: I have a few questions.

I presume that if there is two repos with the same application, then the repo with the highest "priority" is the one which gets to decide what the "preferred signing key" is?

As for the list of versions, I presume that all versions would be shown, but we would disable/otherwise-inform-the-user that certain versions are incompatible. Right now, we do a poor job of that (even without the "fdroid and upstream APKs in the same repo").

About the preferred signing key, that is first defined by what is actually installed. For a newly installed app, then yes, the highest priority repo determines the preferred signing key, just the same as all other metadata.

As for listing, start with whatever is easiest. I think the best behavior would be to hide all incompatible versions. We can handle out of date versions via a general warning, or maybe with an "Show all" mode.

The first step of this is to support proper reordering of repositories in !435.

I've adapted the latest mockup from @crwinfrey about the versions list to suggest how I think this should behave. The think I like about carries mockups is that once you select a version we get to show more info about it. In this case where we have a relatively difficult idea to convey (i.e. mismatching signatures) then we could show "This version cannot be installed" in the versions list, and then when expanded explain further.

Note that we already have an "Expert Mode" setting which we could piggy back off for my suggestion above.

Thoughts @eighthave, @crwinfrey? Happy to explain the problem we're trying to solve in more detail if required @crwinfrey.

Hey @pserwylo, this seems to be a good solution. The one thing I would consider changing is the color. Red makes sense, but it's pretty harsh and draws a lot of attention. I would use red if it's critical for the user to take action against something. But, in this case, we're not allowing users to install the version anyway. I think gray would be a better choice. Something like #818181.

In the meantime, it is pretty easy to start off with something simple based on what we already have. Below is a screenshot of me piggy-backing off the "Incompatible Reasons" functionality, by adding "Signed by different key" to the list of incompatible reasons:

Happy to start with this and then improve based on feedback to my earlier mockup and the implementation of the new versions list shown in #749 (closed).

Thanks for the quick reply. Makes sense re: red. The fact that we even put the word "Installed" or "Can't install" is a huge improvement already in terms of usability here anyway.

I found a good test case for this: if you use a Google APIs emulator, then it'll have Play Services installed. Currently, that will then cause UnifiedNlp to show up since it has the same packageName but different signing key. When this is fixed, Play Services will no longer show up as UnifiedNlp because the signing key will always be different.

changed milestone to %0.103 - UX Overhaul

In terms of the UI for representing the uninstallable APKs, I think we should do whatever is easiest for now, as long as it doesn't appear prominently. I think it would be fine to release this with uninstallable APKs entirely hidden. That info is really mostly useful in edge cases, and it can easily be overwhelming to users. So we'll need to think about how it should best be represented. But this functionality will really improve the usability for lots of users who sometimes install from Play/etc and other times from other app stores

Also, I should point out, we should also hide the apps in the Installed list based on this info, e.g. in the screenshot I send, UnifiedNlp should not show up at all as installed when its actually Google Play Services.

changed milestone to %1.0

I wanted to get part of this done for 0.103, if that is okay. That part would include excluding uninstallable apps from the installed apps list, or at least not showing an uninstall button.

Right now, trying to uninstall a system app (like talkback or UnifiedNlp) results in a crash, with: http://sprunge.us/bBVJ

It's a different issue from this I'm sure, but I think we could get started with not showing system apps to improve usability.

mentioned in merge request !478 (merged)

mentioned in issue #953 (closed)

fdroidserver#291 (closed) and fdroidserver#153 are also related.

mentioned in issue #1035 (closed)

added db label

mentioned in issue #1044

added apksig label

So my plan for this is the following:

• Bring the unit tests for "Current Version" up to scratch with our goal of both multi-repo, and also multi-sig (I think a recent commit I did had better support for multi-repo, but it doesn't have good support for multi-sig yet).
  • The test will no doubt fail, so I'll then change the relevant queries so that the CV is calculated correctly.
• Change the query which returns apk versions to display in AppDetails2 so that if the app is installed, then only those with the same sig are displayed.
  • In the future we can also add a "Showing 3 of 5 versions" or some other sort of feedback, but that isn't required at this point for what we want.

@eighthave: Is that is all that is required - Proper CV calculation which takes into account the current sig of an installed app, and only showing apks with the same sig (if installed, otherwise all are shown)?

mentioned in merge request !534 (merged)

I think this was completely wrapped up in !552 (merged), so closing. For completness, I didn't implement the version list UI that was mocked up above, because we instead hide versions that belong to apps with an incompatible signer.

closed

@pserwylo Is there any plan to still implement a UI for incompatible versions? Because right now if you have a local debug version of an app installed, I think all versions disappear from the UI in fdroid. Also it might be confusing why some versions are shown for some people but not for others.

@Bubu - I don't have any specific plans myself, but I'd love if someone was able to implement it for the reasons that you described. Perhaps if someone ever stumbles across #903 then it would be the right time to implement this. Alternatively, it could perhaps be done with a relatively small UI change to the current versions list. If anyone comes across this comment and would like some pointers on how to go about implementing this, please don't hesitate to ping me and I'll be happy to offer pointers on where to start.

The UX for handling showing the uninstallable, incompatible APKs will be quite a challenge to get right, and most users will never need it. So it is something that we should discuss thoroughly and not rush.

mentioned in issue #1115 (closed)

I don't believe the current behavior provides a good experience for the user. For example, let's say that I am a new user to F-Droid. I have a bunch of apps installed from Google Play, but I want to switch them over to F-Droid. However, until I uninstall the app, I can't tell which version F-Droid has (without going to f-droid.org). So if I have LibreOffice Viewer 5.3.0.0.alpha1 installed, I would have to uninstall it before I could see that the latest available version in F-Droid is 5.2.3.1.

Given the overlap between Google Play and F-Droid mentioned by @sorenstoutner, I think this is not just an edge case.

My reasoning is that almost all users start out with the Play Store, and many people use an open source app without knowing about F-Droid. It could be that they first heard about F-Droid from the OSS apps they already use (from the Play Store). So, new users in particular would have Play Store versions before installing F-Droid, and they would immediately encounter this key conflict.

mentioned in issue #1118 (closed)

mentioned in issue #1125 (closed)

marked this issue as related to #1115 (closed)

@sorenstoutner and @razzintown, thanks for the comments. I agree that this is more common than anticipated. I've commented in #1115 (closed) about the immediate fix to make it more usable, and also the longer term fix to this usability issue.