No support for Google External Dependency Manager?

[revolt3r]

Why would one need to import Google Play Services and Google Install Referrer manually when Google External Dependency Manager exists? It can handle solving dependency / versioning conflicts automatically.
Take an example from MaxSdk

[revolt3r]

Just place this file named "Dependencies.xml" in the Editor folder of the package

<androidPackages>
        <androidPackage spec="com.android.installreferrer:installreferrer:2.2" />
        <androidPackage spec="com.google.android.gms:play-services-ads-identifier:17.0.1" />
</androidPackages>

[dongnhdongnh]

I agree. That's a time saver

[uerceg]

Hey @revolt3r

Thanks for the suggestion. By taking a brief look, that seems to be Unity plugin made by Google which is in charge of handling Google dependencies?

In theory, way how we advise people to add install referrer and ads-identifier dependencies are written long time ago and probably need a refresh in that chapter (which we actually have as work in progress right now) because nowadays AARs can simply be taken directly from Maven repo and used. This plugin you mentioned sounds interesting, but looks to me just like another possible way of adding these dependencies. By no means we consider the way we advise in README to be the one you must take. Point of that chapter is simply that at the end of the day, it would be good for you to include those dependencies into your app. But if you're gonna follow the README and use JAR/AAR files directly or use Google External Dependency Manager - that's fully up to you.

[revolt3r]

Hey @uerceg

Thanks for the update.
Most of the unity SDK creators that use common android libraries (from maven) include Google Dependency Manager in their packages, for example, Firebase, Facebook and MaxSDK. This has become a standard in the industry and it's the easiest way to manage the version conflicts and dependencies between different unity SDKs.

You could at least mention the Dependencies.xml template in the documentation because it would be easier for most of the developers.

[uerceg]

I see. Thanks for the explanation. 👍 We'll need to discuss this a bit more on our end because this what you described above is exactly the thing we are trying not to do with our SDKs - make them depend on some 3rd party things because our SDK itself is already 3rd party dependency in clients' apps. There's also (minor, but still) licensing moment which we need to pay attention to when we make our SDK include third party things, etc. I'd say that for some short term future, we'll try to clean up README chapter which mentions this, try to explain more that we don't really have strong preference how these Android dependencies are added and mention Google External Dependency Manager as an option to add them as well. But like said, for now we will not take down the road of making our SDK to include GEDM, but not closing that door for the future. We'll definitely discuss this internally a bit more.

[visiongamesstudioz]

@revolt3r Thanks. this solved my problem with dependency conflicts.

[epsmarkh]

I see. Thanks for the explanation. 👍 We'll need to discuss this a bit more on our end because this what you described above is exactly the thing we are trying not to do with our SDKs - make them depend on some 3rd party things because our SDK itself is already 3rd party dependency in clients' apps. There's also (minor, but still) licensing moment which we need to pay attention to when we make our SDK include third party things, etc. I'd say that for some short term future, we'll try to clean up README chapter which mentions this, try to explain more that we don't really have strong preference how these Android dependencies are added and mention Google External Dependency Manager as an option to add them as well. But like said, for now we will not take down the road of making our SDK to include GEDM, but not closing that door for the future. We'll definitely discuss this internally a bit more.

You already have dependencies which is the whole reason this issues exists. If you don't want to include External Dependency Manager in your package, maybe just include the dependencies.xml file. This way people that have the External Dependency Manager installed or want to add it will benefit straight away and you don't have to include anything you don't wish.

[uerceg]

Hi @epsmarkh,

Thanks for the message. It is true that there are dependencies which our SDK depends for some features to work or not, but by no means are those mandatory dependencies. If you check what the dependencies are, they are pretty much Google libraries which are needed for attribution logic inside of the apps which are being distributed via Google Play Store. Even though that might be primary use case for lots of apps, we are also having numerous clients who are distributing their Android apps outside of Google Play Store and who are thinking of auto-importing these dependencies as absolutely not needed step.

For the time being, we will proceed with @revolt3r's comment and include these suggestions inside of the README.

Question for you guys who are users of this Unity package - if we would include Dependencies.xml inside of Editor directory and state these dependencies to be added, is there a way for users to instruct that they don't want those dependencies to be added to their app even though our Unity package is stating them (by this I don't mean the way in which users simply go to content of our Unity package and either delete Dependencies.xml from Editor folder or comment out those dependencies)?