11 Jun 2020 |
Bubu | or at least some/most of it? | 20:24:40 |
cdesai | Bubu: I was looking at https://github.com/devasworski/Corona-Info/blob/v1.2/Android/app/build.gradle#L37 | 20:24:49 |
cdesai | that pulls in https://github.com/mapbox/mapbox-events-android/blob/master/liblocation/src/main/java/com/mapbox/android/core/location/GoogleLocationEngineImpl.java | 20:25:21 |
Bubu | which uses gms | 20:25:58 |
Bubu | but I guess this still doesn't ship with the apk | 20:28:01 |
cdesai | yeah I don't see it in the apk | 20:28:31 |
Bubu | So you need it at build time? 🤔 | 20:30:18 |
wb9688 | Bubu: https://developer.android.com/google/play/billing/getting-ready#dependency i.e. "com.android.billingclient:billing", which seems to be open-source as it's on https://developer.android.com/reference/com/android/billingclient/api/BillingClient. Apparently the AIDL is deprecated. | 20:30:07 |
wb9688 | I don't understand why they'd put it in AOSP if it basically requires the proprietary GPlay anyway | 20:31:20 |
Bubu | cdesai: mapbox library has a compileOnly dependency to com.google.android.gms.location (or whatever the excat packagename) | 20:33:08 |
cdesai | yes, https://github.com/mapbox/mapbox-events-android/blob/master/liblocation/build.gradle#L31 | 20:35:01 |
Bubu | so. mh? what exactly does this mean for it being free software? | 20:35:46 |
Bubu | I cannot compile it without a proprietary library | 20:36:03 |
Bubu | but after it's compiled it doesn;t contain any proprietary code? | 20:36:18 |
Bubu | This is a bit confusing. | 20:36:28 |
wb9688 | Bubu: Compile-only have a few use cases: stuff that's actually only used compile time e.g. annotation processors, optional dependencies, or when you need its API but it's provided at runtime. My guess would be the second option in this case. | 20:45:44 |
Bubu | So as a consumer of that library, if I'd use that functionality, I'd have to provide the dependency myself. | 20:47:33 |
Bubu | that makes sense and could very well be the case. | 20:47:42 |
wb9688 | Does F-Droid support building multiple build variants of an app? And would it handle upgrading properly or will the build variant need a separate package name then? | 22:37:20 |
Bubu | wb9688: I'm not quite sure what you want to accomplish | 22:39:17 |
Bubu | and app (= same packageid and signature) will always be updated by f-droid to the recommended version | 22:39:49 |
Bubu | unless it's incompatible because of uses-feature or architecture | 22:40:17 |
wb9688 | Bubu: A build variant of NewPipe Legacy with Conscrypt and a build variant without Conscrypt. | 22:41:26 |
Bubu | well f-droid does encforce maxsdk | 22:41:46 |
Bubu | even if google play deprecated that | 22:41:58 |
wb9688 | Bubu: It wouldn't change anything about supported SDK versions or whatever, just a build variant with the Conscrypt libary and one without. Conscrypt would allow TLS 1.2 support on devices not supporting it, but it would also add some MBs of bloat, so not all people want that apparently. | 22:43:41 |
Bubu | I don't think there's a way a package manager could distinguish those variants though | 22:44:44 |
Bubu | so f-droid wouldn't know which version to update to | 22:44:58 |
Bubu | wb9688: Have you read this? https://f-droid.org/en/2020/05/29/android-updates-and-tls-connections.html | 22:47:43 |
izzy | FYI: I've just finished my triage run on RFP. Killed about 30 issues (closed for various reasons), so we're below 300 open ones again. | 23:03:37 |