Yes, we should move away from SHA1. The bad news is that if you want to support Android releases older than 4.3, you have to continue signing APKs with SHA1. So attackers would have to create two SHA1 collisions: in the APK signature and the GPG signature. Plus the weakness in SHA1 is mostly related to when the attacker can pre-prepare the file being attacked. So someone could upload an app that is properly pre-prepared for SHA-1 collisions, but then why bother with a difficult SHA-1 collision when you could just stick the code into the app? Long story short, this is a very low risk vulnerability in terms of F-Droid.
In the APK signature? How can one could verify the signature if different apk is signed by different key? The only key a newcomer could trust is the gpg key but apks are signed with SHA1!
Its true that the GPG signatures still use SHA1 as the digest algorithm. SHA1 is only deprecated for CA certificates. For files, it is still valid.
$ curl https://f-droid.org/FDroid.apk.asc | pgpdump
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 648 100 648 0 0 420 0 0:00:01 0:00:01 --:--:-- 420
Old: Signature Packet(tag 2)(412 bytes)
Ver 4 - new
Sig type - Signature of a binary document(0x00).
Pub alg - RSA Encrypt or Sign(pub 1)
Hash alg - SHA1(hash 2)
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Sat Apr 8 07:23:01 CEST 2017
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0x7A029E54DD5DCE7A
Hash left 2 bytes - 7e 52
RSA m^d mod n(3071 bits) - ...
-> PKCS-1