🔧 Expose play services location version

[apalala-dev]

Description

Plugins might have compatibility problems with play-services-location version. We used v21 but it includes a breaking change and can't work with v20. This change let users define which version they want to use in gradle.

Checklist

Before creating any Pull Request, confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).

• [x] 📕 I read the Contributing page.
• [x] 🤝 I match the actual coding style.
• [x] ✅ I ran flutter analyze without any issues.

Breaking Change

• [ ] 🛠 My feature contain breaking change.

If your feature break something, please detail it

[christocracy]

LGTM.

However, for future-proofing, you should also implement an ext var for this one too (all androidx deps should be considered candidates, excluding those related to testing). You don’t have to document all your vars but at least it’s available in an emergency, where the user can fix their problem in their app’s Config, rather than having to fix it in the plugin. If the user doesn’t define it in their android/build.gradle, you just fallback to your defined DEFAULT_EXIF_INTERFACE_VERSION = “1.3.5”.

Eg: ext.exifInterfaceVersion

'androidx.exifinterface:exifinterface:1.3.5'

[christocracy]

And this one, as well (it’s almost implemented anyway):

ext.cameraVersion?

def camerax_version = "1.2.0"
    implementation "androidx.camera:camera-core:${camerax_version}"
    implementation "androidx.camera:camera-camera2:${camerax_version}"
    implementation "androidx.camera:camera-lifecycle:${camerax_version}"
    implementation "androidx.camera:camera-video:${camerax_version}"

    implementation "androidx.camera:camera-view:${camerax_version}"
    implementation "androidx.camera:camera-extensions:${camerax_version}"

[apalala-dev]

Thanks for your feedback! Greatly appreciate 🙏

While I agree that adding more configuration to the gradle file is nice, I think that we should add some minimal version as well. In our case, camerax changes a lot for instance and we tend to use the latest version because of its new features. However, if someone overrides to use a lower version that didn't include a feature that we use, I guess it will break ?

I thought about adding some guards like you did yourself:

def locationMajorVersion = playServicesLocationVersion.split('\\.')[0] as int
if (locationMajorVersion > 20) {
    println("*****************************************************");
    println("* [WARNING] background-geolocation requires a maximum googlePlayServicesLocationVersion of 20.0.0 due to breaking changes in v21");;
    println("* googlePlayServicesLocationVersion has been overridden to $DEFAULT_PLAY_SERVICES_LOCATION_VERSION");
    println("*****************************************************");
    playServicesLocationVersion = DEFAULT_PLAY_SERVICES_LOCATION_VERSION
}

Among the fields I'd like to make more customizable with a minimal version check, there are:

• minSdkVersion
• compileSdkVersion
• exifInterface version
• camerax version

Fields that might be customizable:

• kotlin version
• gradle version
• other dependencies (rxjava, guava...)

Although I am not sure about these.

[christocracy]

In our case, camerax changes a lot

Sure. It’s probably unusual for a developer to use multiple camera plugins.