Parts of the code using hardcoded `Constants.GMS_PACKAGE_NAME` not build flavour aware?

[oSumAtrIX]

In many places of GmsCore, Constants.GMS_PACKAGE_NAME is used when the app package name is expected. When building the user flavour, this package name remains hardcoded. This does not look to be intended.

Here is an example:

https://github.com/microg/GmsCore/blob/master/play-services-maps/core/mapbox/src/main/kotlin/org/microg/gms/maps/mapbox/utils/MultiArchLoader.kt#L45

Another:

https://github.com/microg/GmsCore/blob/master/play-services-base/src/main/java/com/google/android/gms/common/GooglePlayServicesUtil.java#L140

For both, the constant should point to the app's package name, so when the user flavour is used, the user flavour package name is used.

[mar-v-in]

For the first case, indeed the mapContext package name would be more accurate.

The second case is for the play-services-base library. That one doesn't have a build flavor and also isn't meant to have one, it's meant to be used by third party apps that want to connect to Play Services or microG. We eventually want it to be able to connect to the user package name, but that should be as an alternative selected at runtime, not at compile time - as at compile time you can't know which other package might be installed on the same device.

[oSumAtrIX]

but that should be as an alternative selected at runtime

Is play-services-base supposed to be used as a "library" that other apps can add as a dependency? If this is a module that's later compiled into GmsCore, shouldn't it point to its own package name? Say there is an OS where MicroG GmsCore is installed both as a user install and the regular install. As of now, with the hardcoded constant in both cases, the app would connect to the regular install. I believe this is not the intended behaviour. However, if the line of code I linked uses the own compiled package name, then it will point to the corresponding flavour correctly.

[mar-v-in]

Is play-services-base supposed to be used as a "library" that other apps can add as a dependency?

It is. Some open source apps use it to easily replace play services when creating fully free software variants of their software. Popular examples include Fennec (Firefox for F-Droid) and Organic Maps.

[oSumAtrIX]

But MicroG GmsCore builds this library and inlines it into the final APK. I am failing to understand the architecture here. I was under the impression that apps are supposed to use this library effectively through "connecting" to GmsCore and not as a standalone library. play-services-base also does not seem to be published as a standalone library either to communicate otherwise. However play-services-base does reference GMS package name, so I suppose this library is supposed to be a replacement SDK for apps to connect to GMS, but then, why is it inlined into the GmsCore APK?

[mar-v-in]

play-services-base also does not seem to be published as a standalone library either to communicate otherwise

The org.microg.gms:play-services-base artifact is available on Maven Central, it's supposed to provide approximately the same functionality as the com.google.android.gms:play-services-base artifact Google provides.

However play-services-base does reference GMS package name, so I suppose this library is supposed to be a replacement SDK for apps to connect to GMS

Exactly. Just to be precise, it is supposed to also be able to connect to microG -user variant eventually, but we're not there yet.

why is it inlined into the GmsCore APK?

Well, for once, there are a lot of classes and AIDL interfaces shared between the client library and implementation. Also, some of the clients are actually used in microG itself, e.g. the maps view in microG location settings (where the location reported to an app is displayed) is provided through the play-services-maps library.

[oSumAtrIX]

supposed to also be able to connect to microG -user variant eventually

It makes sense that the library is expected to connect to the microG user variant eventually. Currently, GmsCore inlines this library into the final APK. When compiling GmsCore for the user variant, the library connect incorrectly to GMS instead of GmsCore. While this did not cause many issues on my end, we had to fork GmsCore to rewrite the hardcoded GMS package names to fix a couple of issues affecting us.

Our current approach combines build-time constants with context.packageName. Since you intend for this library to be used by apps that need to connect to either the user or regular variant at runtime, a compile-time constant alone would be insufficient.

It seems logical for the library to be available for each variant, meaning there should be separate publishes for the user and regular variants. This way, apps can choose to connect to either the user flavor or the regular flavor. A purely static or compile-time approach appears to make sense, as it is unlikely that apps would need to dynamically target the regular or user flavors.

[mar-v-in]

It seems logical for the library to be available for each variant, meaning there should be separate publishes for the user and regular variants. This way, apps can choose to connect to either the user flavor or the regular flavor. A purely static or compile-time approach appears to make sense, as it is unlikely that apps would need to dynamically target the regular or user flavors.

I very much disagree: if there are multiple variants of the library, app developers would need to also provide multiple variants of the apps. Most app developers don't want to target a specific service implementation, they want their app to run. If a system only has official gms, they want the app to use official gms. If the system only has a microG user variant, they want the app to use that. Whatever provides the feature they need is fine.

The only case where it gets complicated is when multiple services provide the feature needed by the app.

[oSumAtrIX]

#3401 might close this