Peter Serwylo efdf328fd3 Clarify a limitation in the current implementation ...

Two repositories can (and always could) end up with the same exact .apk file.
If that .apk is the "suggested version", then we should eliminate the idea of
"suggested version code" and instead have a "suggested apk" (which implicitly
includes the repository it comes from, so we choose the one with the better
priority). Right now, we kind of assume that it doesn't matter which repo
provides the suggested apk, as long as one of them has an .apk with the correct
version code and signing key.

It shouldn't _particularly_ matter from a security perspective, because
a malicious repo wont be able to trick a user into installing an apk with a
different signing key, but it would be good to iron this out.

This commit adds a TODO explaining this for th ebenefit of any CRer.

2016-10-06 03:03:02 +11:00

..

libs/binaryDeps

move main project files into standard gradle/Android Studio layout

2016-03-28 12:12:37 +02:00

src

Clarify a limitation in the current implementation

2016-10-06 03:03:02 +11:00

tools

remove scripts for creating update.zip, moved to priv-ext

2016-08-11 16:59:59 +02:00

build.gradle

gradle: bump plugin version to 2.2.0

2016-09-28 21:58:27 +01:00

proguard-rules.pro

move main project files into standard gradle/Android Studio layout

2016-03-28 12:12:37 +02:00