Crashlytics could not find the resource file generated by Google Services.You may need to execute the :processGoogleServices Task
i read the solution from this qusetion Crashlytics could not find the resource file generated by Google Services. You may need to execute the :process<Variant>GoogleServices Task
but i didn't succeded to run this command in my unity project
./gradlew :app:processProdReleaseGoogleServices or ./gradlew :app:processDevReleaseGoogleServices
how can i run it?
A tricky bit with the Unity SDK is that because Firebase still supports versions of Unity that predate a total move to gradle (I believe 2019.4 is when Unity switched over entirely, the earliest supported version right now is 2017.4), many Android specific solutions (such as the one you linked) won't function. If you did want to try it, you can select "Export Project" in your build settings -- but I don't think this will help:
It sounds instead like you're missing Plugins/Android/FirebaseApp.androidlib or Plugins/Android/FirebaseCrashlytics.androidlib. These are generated by the Firebase plugins (obviously FirebaseCrashlytics.androidlib is specific to Crashlytics -- you won't see that one otherwise) as part of a processing step to simulate what the Play Services gradle plugin would do in a typical Android application or game.
Some things to try:
Make sure you're on a supported version of Unity (2017.4 or newer -- Firebase does not officially support alphas or betas).
Ensure that you have a valid google-services.json file added and that Crashlytics has been added to your backend (full instructions here to redownload).
Re-add FirebaseCrashlytics and ensure that you leave everything checked.
Ensure that you have the latest Crashlytics plugin (currently 7.1.0). You can download just Crashlytics now from this site, but make sure you don't mix and match versions with other Firebase plugins.
And if none of these work, sometimes small changes in build environments expose unexpected issues. Your best bet will be to file an issue here with everything you've tried.
Related
I have an SDK that uses C++ code. The SDK exports 4 different modules in a maven repo that I publish on either a local maven repo or on GitHub packages.
The apps that consume the SDK should be able to use Firebase Crashlytics and get reports of crashes in the native code as well.
The first problem I have is that I need to provide to the Firebase plugin the folders unstrippedNativeLibsDir and strippedNativeLibsDir:
firebaseCrashlytics {
nativeSymbolUploadEnabled true
unstrippedNativeLibsDir "???"
strippedNativeLibsDir "???"
}
If I go to the project where I build the SDK I can see: build/intermediates/merged_native_libs/release and build/intermediates/stripped_native_libs.
Are these the unstripped and stripped folder respectively?
Is there any documentation about what exactly those folders are supposed to contain?
Anyway if I configure the app firebaseCrashlytics to point to these folders I still need to fix another issue.
I get:
Crashlytics could not find NDK build tasks on which to depend. You many need to manually enforce task dependencies
It looks like since I'm building the libs that use the NDK in another project, then the Firebase plugin does not work.
What am I supposed to do?
Is it possible to get the Crashlytics NDK working even if I build the libraries independently with a separate project?
The only way I made it work was to build the libraries along with the app. The libraries were in separate repos anyway but I included them as sub-repositories in the app.
In this way, you solve the issue of not finding NDK build tasks on which to depend.
I know this is not the answer though
I'm using Unity 2019.3.4f1 and Firebase Package 6.15.2 and when I import the Custom Package the Package Manager Resolver asks to change the "/manifest.json".
When I click "Add Selected Registries", Unity starts to Uninstall the packages and stay on its hours with this message: "Uninstalling the following packages: Firebase Authentication"
Package Manager Resolver
I can't deploy or play the game without this message appears.
What you're running into is that newer versions of Unity support a package manager that makes it easier to install and manage dependencies. Newer versions of the Firebase SDK can optionally take advantage of this.
I can't quite tell what your specific issue is, but there are a couple routes forward.
The simplest is to just click "Disable Registry Edition." If you don't feel like messing with this system at all, just click this button and work with Unity packages as you're probably expecting.
Otherwise, you can click "Add Selected Registries." This will kick off a somewhat complex process where:
The Firebase plugin adds a "Scoped Registry" to Unity (this is that code you see in the "After" pane). This tells Unity about Google's package repository.
The Plugin then looks for any package that is included in the registry and uninstalls it to avoid having it included twice.
The Plugin adds the package it uninstalled to your package manifest. This lets you maintain and update the Firebase plugin right in Unity with the "Package Manager" window:
There are plenty of reasons why you'd want to do this. First, the Firebase Unity SDK is HUGE on disk -- much larger than the SDK is even in your project. The reason is that it has redundant copies of every Firebase library for both legacy .NET3 projects and for modern .NET4 projects. Each unitypackage also has to include all of its dependencies -- that means that FirebaseCore is redundantly included in every unitypackage.
Second, what gets me the most, is that the Firebase plugin is too big to fit into a GitHub repo without Git LFS. This is because one or more of the libraries needed to support Linux is larger than a single source file can be. When you use the package manager, this stuff is kept out of your source repository (if you don't commit the Library/ directory, which you shouldn't) keeping your size in the cloud down and making this workaround unnecessary.
Third, as illustrated in the screenshot I included above, it's just easier to upgrade and downgrade the Firebase SDK as needed when you use the package manager. You no longer have to try to remember which Firebase libraries you've installed, you can see them in a neat list! You can also easily uninstall Firebase features that you don't need without worrying too much about large dependencies laying around (you still have to manually clean up some native plugins).
You can also perform all of this manually! Instead of downloading the Unity SDK, you can manually perform the steps as outlined here. Namely you can add:
"scopedRegistries": [
{
"name": "Game Package Registry by Google",
"url": "https://unityregistry-pa.googleapis.com",
"scopes": [
"com.google"
]
}
]
to the end of your Packages/manifest.json as indicated in that popup window. Then install and manage the Firebase plugin that way without worrying about migration at all.
EDIT:
I also should mention that if you do think that you're running into a bug, the system responsible for the dialog you're seeing is known as the "External Dependency Manager for Unity." You can file issues directly on its GitHub page.
How do you setup google firebase dynamic links, deep linking, in a xamarin forms app?
This is how I setup Firebase Dynamic Links in Android project of my Xamarin Forms App, so most of this will apply directly to android. I will work on finishing and documenting the iOS implementation in the future.
Disclaimer: I'm not an expert, any or all of this could be wrong. It's just what worked for me and my basic understanding. Please let me know if there are any errors and let's improve our collective intelligence of the Xamarin Community
If you don't already know what Dynamic Links are, watch the 2 min video, it's a great overview. https://firebase.google.com/docs/dynamic-links/
The Setup
Setup is broken up into 2 parts.
Part 1 - Configure the Dynamic Links in the Firebase Console (Easy)
Part 2 - Configure your app to be able to receive and process the Deep Links (Not as Easy)
Part 1 - Configure the Dynamic Links in the Firebase Console (Easy)
1- Setup a free firebase account at https://firebase.google.com/
2- Create a project.
3- Create a new dynamic link, the tab is at the bottom of the 'Grow' section.
It will generate a static domain name for you based off of your project name. Ex. 'https://myproject.page.link'
Short Link url is what users will click on to navigate to your appstore or launch your app.
Deep Link url is what actually gets sent into your app for you to work with. Ex 'https://myproject.com/MainPage'
iOS behavior. Currently set mine to open the link in a url browser, as my app is not connected to it yet.
Android behavior Very Important but not as hard as my explanation makes it look.
Here is where you register your app with firebase. The package name should be easy, use the same one as defined in your
apps Android properties. Ex 'com.mycompany.appname'
Adding the signing certs SHA-1 and SHA-256 are required for Dynamic Links, which is what we are doing here.
Microsoft has a great guide on this, better than I can explain. here
Download the google-services.json file - You will need it later. Also, you will need the one that has incorporated the SHA cert details in it.
Ignore the instructions for adding the firebase SDK, we will add these to our project later using Nuget packages.
When this is all done your app should be selectable in a dropdown for the android behavior.
Finally, add any extra tags to your dynamic link url if you want, its optional.
And that's it! Now you should have a working short link. When used on an android device it should already be able to determine if the app is already installed or not, and then either direct the user to the play store or open the app. However, it won't do anything with that deep link url that you set. That brings us to the next part.
Part 2 - Configure your app to be able to receive and process the Deep Links (Not as Easy)
1- Versions, might be important.
2- Nuget Packages - Hopefully this goes smoother for you than it did for me.
3- The Code
3a- Intent Filters
3b- Handling the Deep Link
1- Versions.
I was having a lot of issues trying to get dynamic/deep linking to work. So I went back and updated everything to the newest versions available at the time.
Visual Studio Professional 2017 - 15.7.5
.NET Framework 4.7.03056
Xamarin 4.10.10.2
Xamarin.Android SDK 8.3.3.2
Android SDK Manager - Got the latest. Android 8.1 API 27 and Android 8.0 API 26 (Targeting 8.1 might be required)
Android Properties -
-Application - Compile using Android Version(Target Framework): Android 8.1 Oreo
-Android Manifest: Target Android Version: Use Compile SDK Version(haven't tried targetting 8.1 directly, might work). My min target is still Android 4.4 API 19 Kit Kat
2- Nuget Packages. These are just for the Android project. MyApp.Android
You shouldn't have to add anything into the .NET Standard Project, just make sure the Xamarin.Forms Versions match
Below is what I did
Update:
Xamarin.Forms - updated to 3.0.0.482510
Install:
This is where it immediately got annoying for me. Issues here are what lead me to go back and update my Android API Levels to the most recent, 8.1
Xamarin.Firebase.Dynamic.Links by Xamarin Inc v60.1142.1 is what you want to install.
The other dependencies should automatically install. In my case, they did not.
Dependency MonoAndroid,Version=v8.0 is important here. That should be the SDK API version that your app is set to compile against.
However, the other dependencies like Xamarin.GooglePlayServices.Basement (= 60.1142.1) have nested dependencies of their own that require MonoAndroid,Version=v8.1
So if you run into issues installing the Dynamic Links Package, thats where I would recommend looking first.
For my purposes, the nested dependencies were not automatically getting installed, so I went down through each of them and their lists and did them all manually. Even the ones that said not to do manually. It's only 20 or so, but my guess would be if I had my project SDK's set to 8.1 before all of this that it would have gone smoothly.
The CODE
Intent Filters
These are defined in your AndroidManifest.xml file
What do they do? They listen for instructions while your app starts.
When an app start matches a pre-defined filter(short link), they it stores your intended action or data on the Intent Class. That is where we pull the deep link from.
For us, this is what let's the android app receive and begin to process the deep link url that you set all the way back in Part 1.
The firebase dynamic link docs have a good breakdown and example of what to do. here
The android developer docs have a good example and breakdown of this also. here
NOTE Focus on whats between the activity tags. I've just included the other tags to show general structure, in case you haven't edited these before.
That is about the minimum of what you need.
The highlighted line should match the Short Dynamic Link you setup in the established in the Firebase Console.
I'd recommend using a Wildcard like I did in the path prefix.
That way you can make new Dynamic Links and your app can handle them without having to release new versions.
Handling the Deep Link
At this point if your app is launched by the short link, you should be able to catch the deep link during the android startup process and handle it how you want.
All I will cover here is a basic example of how to get the Deep Link as a string.
I pass mine to the main app project (.NET Standard Library) using a simple dependency service.
You can use it however you want though, there's actions it can take in either the App or the App.Android project.
The important thing is getting the deep link.
The firebase docs have good examples, but written in java or whatever language native android uses. here
I'll be showing mostly the same, just in C# examples
Get The Intent.
What is the intent you want to get? The deep link you are sending into your app Ex. "https://mycoolapp.com/mainpage"
You want to get it in the MainActivity. Below is an extremely simplified example, but it's just about that easy. Now you should be able to do what you want with that link inside of your app.
TIPS
Be careful if you have something that interrupts your startup procedures.
My Application uses a splash screen. Part of that is a line of code that creates a new Intent, overwriting the one sent in from the dynamic link
So I have my DeepLinkHandler fire off before that operation, and store the deep link in a static string.
Once it's in a static string I can use a dependency service from the Main App(.NET Standard Library) to call the GetDynamicLinkString method and return the deep link as a string.
How to Test Using an Emulator and Debugger
I have a simple settings page on my app. I added a field that would print the deep link, if it has one.
Fire off the emulator like normal using the debugger. The deep link field should be empty.
With the emulator still running, minimize the app.
Open a browser and enter in the short link url.
This should re-launch your app, but this time the deep link field has the url that you set on the firebase console.
Hope this is able to save someone some headaches.
-Tim
I have a project is working for android browser. Is there a way to generate the apk file?
Also, are there anything that I shoud know before generating the apk file?
There are a few steps to follow in order to generate the Android application file (.apk) from a meteor app:
meteor install-sdk android
Have the mobile-config.js file in your project root (mobile-config.js example)
meteor add-platform android
meteor build ~/your-output-dir --server=yourapp.meteor.com
Then you will have your .apk file in ~/your-output-dir/android/unaligned.apk
If you want to proceed and submit to Google Play Store, here are the steps to follow: https://guide.meteor.com/mobile.html#submitting-android
Hope this helps!
You can build an APK file with meteor build command.
Read more about it in the docs: http://docs.meteor.com/#/full/meteorbuild or by typing meteor help build in your terminal.
Starting with Meteor 1.2, the bundled Android tools have been removed and a system-wide install of the Android SDK is now required. This should make it easier to keep the development toolchain up to date and helps avoid some difficult to diagnose failures. The meteor install-sdk command no longer attempts to download and install the Android tools for you (it has been deprecated and just points you to these instructions).
like imslavko says, meteor build works pretty fine, also if you are looking for more information take a look on this Meteorpedia
It work for me
Reegards
As of now playstore has started giving warning while uploading APK about unoptimised bundle and insisting for uploading Android app bundle.
Insted of generating APK why not generate .aab of your project and reduce size of the application.
For people wondering about how to generate .aab for your existing project can read my blog here:
My blog link
Recently tried the plugin example of Qt.
It didn't work at all and I was confused as to the reason. Then found the solution on one of the forums.
Qt, Application and plugin all three have to be built with the same configuration (Release/Debug)
This works for me as I can build all three in Debug/Release mode. But if I want users to extend my application using plugins I need to provide debug build of my application. (If I provide release build, users will not be able to trouble-shoot the plugin). Qt source is available so it can be built in any mode.
I don't want to provide debug build of my application to users. Is there any work around for this restriction on build mode for plugins?
P.S. I understand users can debug with logging statements, but not sure how many prefer that approach.
This is because Qt has a so called build key which is just a string containing some Qt configuration information, this is documented in the Qt plugin Howto.
So you should just go ahead and provide a debug build of your application for the best results.
You can build debug version (to have compiled in debug configuration) and strip it out of all symbols etc.