Quickstart-unity: Can I change the firebase sdk paths safety?

[ldk18501]

Hello, I have tried the firebask sdk for unity examples and they all worked well by default.
But, in my actual project, I want to manage my project directory structure, so I moved Firebase folder to a git submodule folder.
For example, the origin path of sdk is "Assets/Firebase/...",now is "Assets/SDKModule/Firebase/...".
Then errors occured that the console told me "Unable to find command line tool D:/UnityProject/XXX/Assets..AssetsFirebaseEditorgenerate_xml_from_google_services_json.exe required for Firebase Android resource generation."
So...if it is possible to fix this? Or can the sdk only be used in the default folder path?

[ldk18501]

btw, I found every plugin have a config file such as FirebaseRemoteConfig_XXXXX.txt, there're many path config inside. I modified them to what I need but nothing happened even I have reimported everything.

[airalones]

So we could not change SDK path?

[stewartmiles]

@ldk18501 Unity - especially across different versions - is very particular about where things live in the directory structure. In order to have Unity build components for each platform we needed to lay things out in the current structure. Worse, since older versions of Unity don't have a package manager we need to make sure shared components (e.g Parse, PlayServicesResolver etc.) reside in known locations. Ideally this could be resolved with a package manager that works across all Unity versions, alas we haven't found something reasonable to use yet and our implementation is far from complete.

FYI: The manifest files distributed with the plugin are simply there to assist with upgrades, we use the manifest to calculate the difference in files when importing new versions of the plugin which allows us to clean up stale components.

[fogmoon]

@ldk18501 @stewartmiles
Same issue. I just do not want so many folders with no-uniform name just used by SDK directly to be put in unity project asset root directory. It's hard to maintain without extra wiki or other document to explain them.

I used most Unity third-pard SDK which is just in their own folder. So maybe firebase SDK can also do the same thing.

Thanks.

[stewartmiles]

@fogmoon Firebase is a little more complicated than many SDKs, in addition we support many versions of Unity that most plugin developers don't care about. So I'm afraid not, we need our current layout. Have you considered using source control to handle rollbacks / upgrades?

[UhlmannVincent]

So this can't be done? Firebase and all it's Folders need to be in the root Asset folder of Unity?

[flywithfang]

@ldk18501 @stewartmiles
Same issue. I just do not want so many folders with no-uniform name just used by SDK directly to be put in unity project asset root directory. It's hard to maintain without extra wiki or other document to explain them.

yes, absolutely agree.Firebase messup our project structure and make our version sharing cubersome.

[Ahmed-YehiaGPEL]

Anything new on this issue? I got my whole project structure messed up because of using the SDK, it makes it hard to track changes in the project.

We usually have a thirdparty directory that includes all the SDKs and other thirdparty tools and using Firebase messes up the whole structure, there has to be something we can do about it?

[GeorgeFedoseev]

Please, at least make it one neat folder "Firebase/" in the root Assets directory. Right now it's hard to find stuff and my project's folder structure doesn't look clean.

[ChrisZul]

So I kind of got this partly working. I have most of firebase in a submodule shared across a few different unity apps. What I have to do is inside each project when I add the googleservices files for that project, I also have to copy into the project another folder from the submodule. In this folder there's no CS files or DLLs but the py and exe files from the firebase/editor folder, and also the m2repository folder. Using this method I can share and update firebase across a bunch of apps, and also have my shared tools dependent on the firebase API.

I think that the SDK should support this more seamlessly. simply by using a unity editor call the SDK can find out where it is located in a project and run your import scripts against that. There's no technical reason why the SDK should force itself to be located in a specific folder.

This issue was closed even though a number of users agreed with it and it was not fixed. That itself is the worst thing about this problem. Ignoring your users is very annoying for them. Currently firebase needs to be used to leverage google ads properly, so you guys are extremely privileged. Forcing users into clunky pointless workflows through monopolies is not cool.

[stewartmiles]

@ChrisZul glad you have something working. We do support moving components around in our plugins to a certain extent as we fallback to searching for components using asset GUIDs, if you blow away the asset metadata though everything will break. If you have a particular problem you would like to see addressed, please open an issue describing exactly what isn't working for you and we can take a look.

[ChrisZul]

Thanks for the response @stewartmiles. I would vote for re-opening this current issue, as it already perfectly describes the issue and has a range of interested users already participating in it who would probably be interested in any fixes.

But just to be extra clear, from my experience with what I have to do to get good iOS and Android builds using my submodule, the files which are part of the firebase unity SDK and are not currently happy about being moved around into new paths are as follows:

Firebase/Editor/AnalyticsDependencies.xml
Firebase/Editor/AppDependencies.xml
Firebase/Editor/generate_xml_from_google_services_json.py
Firebase/Editor/generate_xml_from_google_services_json.exe
Firebase/Editor/network_request.py
Firebase/Editor/network_request.exe

Firebase/m2repository/**

Firebase/Plugins/Android/Firebase/AndroidManifest.xml
Firebase/Plugins/Android/Firebase/project.properties

It's possible that not all of these need copying however I copy them into each project from my submodule and then firebase seems to work for me. I am not sure what you would have to do to fix this problem, but basically the way most unity packages work these days is that everything is contained in a folder. Users can move that folder around within their project, and the package continues to work. In a new project Asset GUIDs are all completely recreated so it is not a good way to keep track of things.

[stewartmiles]

The following should already work:

• *Dependencies.xml files really don't care where they live, they must exist under an Editor/ folder. See https://github.com/googlesamples/unity-jar-resolver#android-resolver-usage
• generate_xml_from_google_services_json.{py,exe} is found via asset GUID and only searched via path as a fallback. If the asset metadata isn't changed, this should work fine to move anywhere.
• Firebase/m2repository/** _should_ be found if path relative to Assets is preserved. e.g it can be moved into any subfolder and found via https://github.com/googlesamples/unity-jar-resolver/blob/56d476e23464f797d8c90b5fac0958af2e0887db/source/PlayServicesResolver/src/GradleResolver.cs#L134

I don't think moving the following works:

• The project template in Plugins/Android/Firebase is primarily due to this being treated as a build artifact. We populate this with the config generated google-services.json. I guess it's possible for us to again find the output directory by asset GUID based upon say the AndroidManifest.xml.

w.r.t replacing asset GUIDs / asset metadata, you're going to be totally out of luck, AFAIK, there are a few ways to uniquely identify a file in a Unity project:

1. Asset GUIDs
2. Path relative to Assets/
3. File checksum (very slow, very small chance of hash collisions)

We mostly do (1), with a bit of (2) when looking for maven repos using the subpath as a way to identify a directory, we do not do (3) as things are slow enough.

[nextvern]

I have a problem.

Use SDK version is 6.6.0

Crashlytics library is hard coded as "Asset/Firebase/Editor" path in the VersionInfo.GetEditorGvhVersion() function.
So it fails on "SendBuildEvent".

[chkuang-g]

Hi folks, it has been awhile.

I think you can change most of the Firebase library location as @stewartmiles mentioned.
Be careful with Crashlytics.

Another option for you now is to install Firebase through UPM so that your Assets folder can be clean and shiny.
Instructions
https://firebase.google.com/docs/unity/setup#add-sdks-upm
Known Issues
https://firebase.google.com/docs/unity/setup#known-issues

I will close this one for now.