supporting microG, which has the same packageNames as the Google Apps

The Provides: field is said to be:

Comma-separated list of application IDs that this app provides. In other words, if the user has any of these apps installed, F-Droid will show this app as installed instead. It will also appear if the user clicks on urls linking to the other app IDs. Useful when an app switches package name, or when you want an app to act as multiple apps.

While it might be difficult to actualy force such a behavior, I'd rather make it like the build recipe actually builds a "wrong" package which I can allow with Provides: There is actually one use case for this: Replacing proprietary system apks. E.g. the microG project provides multiple implementations of the geolocation service, one that does only geolocation and one that is meant to be a complete replacement for playservices. Right now, we cannot build the latter one, because the package id is already used by the former one.

Supporting microG is definitely important. This sounds tricky, it could have some nasty side effects if we are not careful since this concept is not part of Android's model nor other app stores that I know of. For your microG example, do you know why they have two versions? Why not just distribute the complete one? My hunch right now is that the solution to this problem lies more in the microG project than in F-Droid.

Well, microg's problem is that iirc only CM and some other roms are patched to allow the network location functionality provided by multiple apps (with different package ids). So for all other, they have to re-use Google's package id instead of org.microg.nlp for the UnifiedNlp stuff.

Older Android versions use com.google.android.location, which is also not a problem, but newer versions rely on com.google.android.gms. That is the package id that gets replaced by the GmsCore package from MicroG and thus conflicts with the UnifiedNlp package using the same id..

Executive summary: com.google.android.gms is used for both, UnifiedNlp and GmsCore replacement from µG. And since we are in open-source wonderland, other apps might do so as well sometime in the future.

Ref: https://github.com/microg/android_packages_apps_UnifiedNlp/issues/49

Do the microg apps work if they are installed as regular apps, and not system/priv-app? What about supporting microg via the OTA update ZIP support added in !181 (merged)?

Changed title: Implement "Provides:" field AND/OR allow multiple apps for a single package id → supporting microG, which has the same packageNames as the Google Apps

Milestone changed to %1.0

Actually this is not only about microg, but a general issue. While package id should be unique, they might not be. Even on purpose: As drop-in-replacements. So the main problem is not that it uses the same id as some system apps (there is a problem because fdroid shows microg being installed regardless if its the system app or the microg version.. i think checking signature should help here), but that we have multiple options that all use the same id. Right now, we have to decided which to build. So imho you should revert the title change and/or open another issue.

UnifiedNlp works without being a system app. Dont know for the complete play-services replacement.

The problem is that Android and its app stores have all been designed around the concept that a single app has a single unique ID that is not shared. We can't change that, so we really shouldn't fight against it. We have enough work to do as it is. Sounds like the microg project needs to decide which app is going to be the "one" replacement for a given Google packageName.

mentioned in issue fdroidclient#831 (closed)

added discussion label

added apksig label

So now that fdroid update and index-v1.jar can support any collection of APKs, I think it is clearer how F-Droid can support these use cases. There will only ever be a single com.google.android.gms on f-droid.org, so the most popular one could be added to f-droid.org. Then to support the different possible variations of com.google.android.gms can be published in their own repos on microg.org. If each variation is published in its own repo, then the highest priority repo will provide the APK and description for com.google.android.gms.

@pserwylo does that sound right based on what's in %1.0 in fdroidclient ?

mentioned in issue fdroidclient#1168