Non Free Deps in F-Droid build

[linsui]

I guess it's pulled in by mapbox, commons-app/apps-android-commons#4994, could you please take a look? Thanks!

https://gitlab.com/linsui/fdroiddata/-/jobs/2716611696

[johan12345]

Oops, I found Google Places to be one culprit - it was mistakenly included as a dependency for all build flavors, even though it's only used in the google variant. 1f36ef6

Not sure if this was the only problem - I thought the old Mapbox version EVMap is currently using was fine. Switching to MapLibre might not work out of the box, as I think it removes support for Mapbox's billing token (see also #141).

[linsui]

I tried the latest commit and got

2022-07-14 11:54:18,009 DEBUG: Found class 'com/google/android/gms/location/LocationResult'
2022-07-14 11:54:18,013 DEBUG: Found class 'com/google/android/gms/tasks/OnSuccessListener'
2022-07-14 11:54:18,023 DEBUG: Found class 'com/google/android/gms/location/LocationRequest'
2022-07-14 11:54:18,029 DEBUG: Found class 'com/google/android/gms/tasks/OnFailureListener'
2022-07-14 11:54:18,046 DEBUG: Found class 'com/google/android/gms/location/FusedLocationProviderClient'
2022-07-14 11:54:18,070 DEBUG: Found class 'com/google/android/gms/location/LocationCallback'

Much less. The remain GMS classes may come from mapbox.

@licaon-kter Could you please help here?

[licaon-kter]

@johan12345 is anymaps-osm not ready?

Random question, // Android Automotive OS app is always based on Google variant but why? Is Google abusing their monopoly by forcing devs to use closed source proprietary libs or else AA won't show their navigation app?

[licaon-kter]

Regarding mapbox, maybe switch to the libre fork and apply the note: https://github.com/maplibre/maplibre-gl-native/blob/main/README.md#android

Testing HEAD now and

+--- com.mapbox.mapboxsdk:mapbox-sdk-services:5.5.0
|    +--- com.mapbox.mapboxsdk:mapbox-sdk-core:5.5.0
|    |    +--- com.google.code.gson:gson:2.8.6
|    |    +--- com.squareup.retrofit2:retrofit:2.7.1 -> 2.9.0 (*)
|    |    +--- com.squareup.retrofit2:converter-gson:2.7.1
|    |    |    +--- com.squareup.retrofit2:retrofit:2.7.1 -> 2.9.0 (*)
|    |    |    \--- com.google.code.gson:gson:2.8.5 -> 2.8.6
|    |    \--- com.squareup.okhttp3:logging-interceptor:3.12.7
|    |         \--- com.squareup.okhttp3:okhttp:3.12.7 -> 4.9.0 (*)
|    +--- com.mapbox.mapboxsdk:mapbox-sdk-geojson:5.5.0
|    |    \--- com.google.code.gson:gson:2.8.6
|    +--- com.mapbox.mapboxsdk:mapbox-sdk-directions-models:5.5.0
|    |    \--- com.mapbox.mapboxsdk:mapbox-sdk-geojson:5.5.0 (*)
|    \--- com.mapbox.mapboxsdk:mapbox-sdk-directions-refresh-models:5.5.0
|         \--- com.mapbox.mapboxsdk:mapbox-sdk-directions-models:5.5.0 (*)

And the APK via apktool shows these strings: https://github.com/mapbox/mapbox-events-android/blob/d73ca293b194376516997b73c5139b28430be671/liblocation/src/main/java/com/mapbox/android/core/location/LocationEngineProvider.java which depends on gms, right?

See this gist: https://gist.github.com/licaon-kter/adfbd89cec2bdbe00ce2a2f061f57720

[johan12345]

Does 682f05b help? I found this comment in the MapLibre repo that suggests simply removing the GMS dependency as it's not required for compiling, and that seems to apply to Mapbox as well.

@licaon-kter

@johan12345 is anymaps-osm not ready?

In principle it would work, but it is based on an ancient version of osmdroid, does not support vector maps (-> worse user experience especially on slow networks), and also some other features regarding marker manipulation are not implemented as far as I remember.

Random question, // Android Automotive OS app is always based on Google variant but why? Is Google abusing their monopoly by forcing devs to use closed source proprietary libs or else AA won't show their navigation app?

Android Auto (i.e. phone connects to car via USB and streams a UI to the car screen) only supports apps that use the UI templates that Google defines in their Car App Library for driver safety reasons. Initially that library was proprietary, but it is now part of AndroidX which is open source. However, Android Auto itself is closed source and I doubt it would run on devices without Google Play Services. So I'm not sure if there is a point in including AA support into the foss flavor, and I'd have to check if it would pull in any closed-source dependencies.

Android Automotive OS (i.e. the car's infotainment itself runs on an Android system, which is currently the case in some recent Volvo, Polestar and Renault cars) does support running arbitrary Android apps, including both flavors of EVMap. But these can only be installed through sideloading (or by coming to an agreement with each car manufacturer), also for safety reasons. So the only option to distribute the app to these cars through the Play Store is to also use the UI templates from the Car App Library.

Regarding mapbox, maybe switch to the libre fork and apply the note: https://github.com/maplibre/maplibre-gl-native/blob/main/README.md#android

As I said, the libre fork seems to remove support for Mapbox's billing token, so probably switching to that would also mean needing to switch to (and pay for) another map provider.

[johan12345]

@linsui
With a foss build using the latest commit (including changes in 682f05b), I could not find any com.google.android.gms classes in the resulting APK anymore. Android Studio's APK analyzer only shows them as "referenced" (as the Mapbox SDK includes references to them that are only actually used if they are on the classpath), but they are not included in the APK.

[licaon-kter]

That reference means that that the lib was build from non-FOSS deps, right? Making the lib itself non-FOSS :(

[johan12345]

The Mapbox SDK is FOSS, licensed under 2-clause BSD: https://github.com/mapbox/mapbox-gl-native-android/blob/android-v9.2.1/LICENSE.md

Besides, the reference just means that the code contains a reference to a class name, not that this class is actually downloaded and used during compile or runtime. I would not count that alone as "being built from non-FOSS dependencies".

[johan12345]

@licaon-kter @linsui Can you please clarify if the latest commit is now fine? As I said, as far as I can see, the app does not include any GMS code anymore, and the one location in mapbox-events-android you linked that references GMS (which, by the way, is included in MapLibre as well) only actually accesses these classes if they are on the classpath, which they are not in this case. If they are not on the classpath, it falls back to Android's own Location API.

Users have also notified me that the app has been removed from F-Droid, apparently after I already addressed the issue. Should I release a new version to make it possible to re-include it?

[johan12345]

I have released a new version 1.3.4 with the fixes mentioned above and opened a MR at fdroiddata to ask for re-enabling the app: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11521

[johan12345]

The F-Droid build scanner still claims to find GMS classes, but I think this is due to a bug on the F-Droid side. See my comment here.

[licaon-kter]

/close this

[johan12345]

Fixed with ed80d7b

[linsui]

Do you add a custom build of mapbox to remove the GMS dep? But F-Droid doesn't allow custom maven repo, either... So should we build it from source? Do note that maplibre 10 has solved this problem.

[johan12345]

The GMS dep has already been excluded before I switched to the custom Maven repo. The custom build was needed to comply with policies from Android Automotive app stores (#281), which require native libraries to be built with the "FORTIFY_SOURCE" flag. This was not active for the binaries that Mapbox provides, as they were built using an old NDK version. I tried to use JitPack, but I think the build was too slow and timed out.

The main reason I have not switched to MapLibre so far is that, as far as I can see, it does not support per-user billing for map tiles from Mapbox - the Mapbox-specific code needed for that has been removed. I would estimate per-tile billing to be much more expensive. If another map provider would support us with free map tiles, I would gladly switch.

[linsui]

Then what should we do? Should we build it from source or use the original lib?

[johan12345]

I think it's fine if you use the original library - apart from the fortify flag there are no changes in the fork. Thanks!
I will think about a better solution for future releases.

[linsui]

That's great. How can I use the original lib? Should I simply revert 9c5582f?

[johan12345]

that should work, yeah

[linsui]

It works, thanks!