Strange F-Droid microG Services Core update behaviour

[M_Dammer]

Can someone explain this strange behaviour of F-Droid to me:
Now and then F-Droid notifies me of an update of microG Services core - I do have the microG repo installed. However, the update looks strange - at the moment it wants to update from version 1.6.7 to 0.2.4. - smells actually more of a downgrade. Because as far as I understand microG core is already part of FP Open the update cannot be applied - makes sense, but what I find really strange is that these updates disappear suddenly as if F-Droid has learned that they would not work after a while.
Really strange!

[Roboe]

There’s no problem at all, just a naming issue.

First of all, FP Open does not include microG. You should have installed it somehow (or you have GApps installed, read below)

---

Android versioning

Every Android app (i.e. a single APK) have two versions:

• One, a readable one, a text string, for users to easily understand
• Two, an integer one, the real version number. This is the version the Android Package Installer uses to reject downgrades, and the version stores like F-Droid use to broadcast updates.

What is happening here is that the version installed (1.6.7, from the F-Droid repo) is actually internally lower than the version-to-update-to (0.2.4, from the microG repo). I don’t know the reason why the readable version of the F-Droid microG is 1.x.x; microG is still in development.

---

Android security concerning app updates

You cannot install the microG’s repo one over the F-Droid’s repo one because they have conflicting signatures (that is; different people have compiled it). That’s an Android authoring integrity protection to avoid malware and data-theft (you should know more about this, I can read “IT Security consultant” in your profile). F-Droid is known to compile from source their shared apps: this ensures the source code matches the release APK if you choose to trust F-Droid’s build servers.

The solution is to uninstall the F-Droid’s repo version and install the up-to-date microG’s repo version (or compile it yourself from source)

---

Conflict: microG vs Google Mobile Services (GApps)

microG conflicts with GApps. To fake GApps, microG apps needs two things:

• Same package signature as GApps: com.google.android.gms (et al.)
• Same signing key as GApps: that’s why you need to install Xposed Framework or Needle for signature spoofing.

These are needed because those apps requiring Google Services check those things before actually using them. And with microG we are trying to fake them through the same API but different implementation.

[M_Dammer]

Thanks @Roboe for the detailed explanation. I am still baffled by what happens here: F-Droid started, check for updates, the unusable update disappears into nirvana and when I check it says that version 0.1 is installed (origin microG repo). No other versions are listed - usually F-Droid lists all available versions. I am getting the impression that the microG devs are faffing with their repository.

[paulakreuzer]

There are two different apps “microg services core” from the microg repo and “microg UnifiedNLP (no GAPPS)” form F-Droid repo. These are not just different versions of the same app.
For some reason “microg services core” is sometimes renamed as “microg UnifiedNLP (no GAPPS)” in F-Droid. But in any case these should be different entries in the list.

[Roboe]

Oh, you are right, I forgot about that!

@Roboe

I don’t know the reason why the readable version of the F-Droid microG is 1.x.x; microG is still in development.

Now I’ve cleared the doubt! Thank you @paulakreuzer for bringing up the UnifiedNLP thing.

Those naming problems are caused because F-Droid uses the package signature (com.google.android.gms in this case) as the app identifier. That’s not a problem in other cases where the same app is available in more than one repo, but this case is special, because there’s a package name conflict with THREE different apps (UnifiedNLP, microG Services Core and Google Mobile Services themselves).

---

One package name to rule them all

F-Droid’s repo includes the UnifiedNLP Android package (APK) in three flavours: GApps, no GApps and no GApps legacy. Only the GApps flavour conflicts with Google Mobile Services.
F-Droid does not include microG Services Core in its own repo, you should add the microG’s repo for that.

The thing is, as I explained above: to impersonate Google Mobile Services (tricking the system or another apps), an app should have the same package signature as them; i.e. com.android.google.gms:

• UnifiedNLP app impersonates GApps at the system level to provide free location services;
• microG Services Core app impresonates GApps at the system level and for other apps, too, to provide GMS-API-compatible services, including location service.
• (if GApps installed) Google Mobile Services app doesn’t need to impersonate itself, but uses that package name, obviously.

Thus, microGSC, UnifiedNLP (GApps) and Google Mobile Services share the same package signature, even when they are different apps, and F-Droid list them as the same app, which causes version singularities (UnifiedNLP is at 1.6.7, microG is at 0.2.4-xxxxxx) and naming problems (they often call UnifiedNLP (GApps) to the microG Services Core app, or UnifiedNLP (GApps) to the actual GApps)

P.S.: All this troubles are caused by Android and Google. We must remember that Google is locking up Android’s freedom by outsourcing system features to their Google Mobile Services. microG tries to reverse that move and let you choose which service (SaaS) you want to use, returning the control back to the user.