When project's product name changes, the resolver refreshing dependencies, any way to spare this step?

[a-l-e-x-d-s-9]

[REQUIRED] Please fill in the following fields:

• Unity editor version: 2020.3.25f1
• External Dependency Manager version: 1.2.168
• Source you installed EDM4U: .unitypackage.
• Features in External Dependency Manager in use: Android Resolver.
• Plugins SDK in use: Firebase Analytics, Firebase Crashlytics, Google Appbundle, Google Asset Delivery, Google Billing.
• Platform you are using the Unity editor on: Linux.

[REQUIRED] Please describe the question here:

I'm using one Unity project to create multiple apps (each with its unique flavor, but based on the same code), each with different package/product name that published as separate app at Google Play Store. I need to switch between the flavors of the app often, and each time Android Resolver scanning everything and it's taking long time, nothing should be actually changed.

1. Is it possible to tell Android Resolver to not be triggered, and just accept that nothing should be changed? Maybe I can use some workaround to spare me this time, it is really problematic with many switches.
2. Each flavor has its unique firebase configuration file, but they all use the same firebase packages. I don't know why the following files keep being change after each Android Resolve run after package name change. Is there a way to spare this changes, or they include an injection of package name that forces them to be updated?

   com.google.firebase.firebase-analytics-unity-8.7.0.aar com.google.firebase.firebase-app-unity-8.7.0.aar com.google.firebase.firebase-common-20.0.0.aar com.google.firebase.firebase-crashlytics-ndk-18.2.5.aar com.google.firebase.firebase-crashlytics-unity-8.7.0.aar com.google.firebase.firebase-installations-unity-8.7.0.aar

[google-oss-bot]

This issue does not seem to follow the issue template. Make sure you provide all the required information.

[a-l-e-x-d-s-9]

@google-oss-bot I followed the issue template for general question precisely. Am I missing something, and someone can specify what's the problem with my template, or @google-oss-bot has bugs?

[paulinon]

Hi @a-l-e-x-d-s-9,

Could you navigate to Assets > External Dependency Manager > Android Resolver > Settings then disable Enable Auto-Resolution and see if this resolves your issue? I recommend using an updated version of the resolver (Version 1.2.169 as of writing).

If this doesn't work, kindly provide the complete steps needed to replicate this behavior.

[a-l-e-x-d-s-9]

Hi @paulinon,

Thank you very much for your help. I've upgraded to 1.2.169. Also in the settings re-disabled auto-resolution and resolution on-build. Now when I've changed the package/product name of the app, it did not triggered Android Resolver to scan. I still haven't tested if it is working with building a release version without problems, but I hope so. Regarding the second question, do you know maybe, why the following firebase files are changed by Android Resolver after package/product name of the app was changed?

com.google.firebase.firebase-analytics-unity-8.7.0.aar com.google.firebase.firebase-app-unity-8.7.0.aar com.google.firebase.firebase-common-20.0.0.aar com.google.firebase.firebase-crashlytics-ndk-18.2.5.aar com.google.firebase.firebase-crashlytics-unity-8.7.0.aar com.google.firebase.firebase-installations-unity-8.7.0.aar

[paulinon]

Hi @a-l-e-x-d-s-9,

Given that those products are dependent on the app's package name, it's possible that the resolver sees this as library conflict given the changes you're making.

I look forward to your results.

[google-oss-bot]

Hey @a-l-e-x-d-s-9. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Since there haven't been any recent updates here, I am going to close this issue.

@a-l-e-x-d-s-9 if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.