In historical Fabric/Crashlytics for Android documentation and various online examples there is mention of the Fabric 'apiSecret' that should be included in your fabric.properties file. However, in the latest official documentation for setup with Gradle, there is no mention of it: https://fabric.io/kits/android/crashlytics/install. It also appears that the Gradle setup is no longer using fabric.properties and instead using the apiKey defined in the AndroidManifest.xml.
What is the recommended way to handle the 'apiSecret' and 'apiKey' in Android Gradle projects?
Currently Google is making the transition from fabric/crashlytics towards firebase/crashlytics. I'd recommend you look into this guide if you're currently implementing crashlytics
https://firebase.google.com/docs/crashlytics/
If going this route, you have to download a .json file from firebase after creating an app project there and include it in your app. No key needed.
Related
When an APK is built with AndroidX libraries, I get a lot of small text files like META-INF/androidx.core_core.version. What is the purpose of these files? How are they used by androidx?
I was recently curious as well, so I browsed the source code a bit.
The first attempt for version information injection was here; it was implemented by adding a meta-data tag into AndroidManifest.xml.
Then came a pair (1, 2) of commits which added a task (into Gradle plugin, that is shared between many/all? androidx libraries), whose sole purpose is to generate the *.version files. This approach replaced the earlier meta-data tag injection, where the reason is (from commit message):
Previously support library tracked its usage by adding meta-data tags
to each library, however that caused issues for certain libraries as
there is a high cost associated with services and meta-data in package
manager.
To work around this issue move to storing version information in java
resource inside the jar META-INF/group_name.version.
However, that doesn't answer the question - as none of these commits mention the reasoning behind storing the version information in androidx libraries.
I've also tried to search for *.version usages in the androidx codebase, but unfortunately couldn't find anything interesting.
Eventually, the author of *.version generation task was kind enough to shed some light on their purpose:
The main purpose for them is for us to be able to track which versions
of androidx libraries are being used by the apps in the play store or
when someone submits a failing repro APK. We also recently started
using in compose inspection tool on studio side to detect what
features should be available given the library version.
I am trying to configure Firebase Crashlytics in my library project. According to Firebase its not possible to configure Crashlytics in the library project.
I am getting this error message.
Crashlytics was applied to an android-library project.
Android-library support is currently an incubating feature.
Help me if you have any solution or workaround.
I just wanted to log library project crashes in Firebase Crashlytics.
I recently worked on a library and from the get go, we knew that we won't be able to integrate an out of the box solution for this as it'll always conflict with consumer apps' implementation of the service like Firebase.
We opted for a different strategy. Handle all the crashes in the library ourselves and then heres what we do with them:
A listener set by the consumer app is notified of the error as a callback
Post the error logs to our own custom API server on next restart of the app and forward these logs onto different services like Firebase.
I understand this is not an exact solution that tells you how to use Firebase Crashlytics in a library but posting here as it gets the same work done.
When an APK is built with AndroidX libraries, I get a lot of small text files like META-INF/androidx.core_core.version. What is the purpose of these files? How are they used by androidx?
I was recently curious as well, so I browsed the source code a bit.
The first attempt for version information injection was here; it was implemented by adding a meta-data tag into AndroidManifest.xml.
Then came a pair (1, 2) of commits which added a task (into Gradle plugin, that is shared between many/all? androidx libraries), whose sole purpose is to generate the *.version files. This approach replaced the earlier meta-data tag injection, where the reason is (from commit message):
Previously support library tracked its usage by adding meta-data tags
to each library, however that caused issues for certain libraries as
there is a high cost associated with services and meta-data in package
manager.
To work around this issue move to storing version information in java
resource inside the jar META-INF/group_name.version.
However, that doesn't answer the question - as none of these commits mention the reasoning behind storing the version information in androidx libraries.
I've also tried to search for *.version usages in the androidx codebase, but unfortunately couldn't find anything interesting.
Eventually, the author of *.version generation task was kind enough to shed some light on their purpose:
The main purpose for them is for us to be able to track which versions
of androidx libraries are being used by the apps in the play store or
when someone submits a failing repro APK. We also recently started
using in compose inspection tool on studio side to detect what
features should be available given the library version.
Is it possible to use Firebase Remote config in an Android library module and still allow the library consumer to use Firebase Remote Config with their own acount?
I have created an Android library that uses Firebase Remote Config to update the library configuration from my Firebase console account.
In my reference/test app that references the library I have my google-services.json in the app directory. Everything works perfectly.
I have just realised that once I provide my library to others as an aar they will potentially have their own google-services.json and use Firebase directly in their own app.
I have searched google but I'm finding it difficult to find out if this is even possible? Has anyone had experience with this setup or know how it should work? The only thing I could think of trying was moving my google-services.json into the library but I couldn't get this working.
Thanks in advance for any help!
Use of Firebase SDKs in third-party modules was never intended by the Firebase team. The SDKs all depend very heavily on a host project that's configured by the app as a whole, not by a module. In fact, you can't use the google-services plugin in the library module, only in an app module.
Remote Config is even more complicated in that it depends heavily on Analytics, which is definitely only viable as an app-level dependency (you can't have two projects collecting Analytics from a single app).
If you try really hard, you might be able to use something like Realtime Database in a third party module where all apps that use it all have access to the same database, but then you'd have to initialize a special FirebaseApp that points to your common project, and make your database world-readable, because you won't have Authentication in place to gate access to individual users.
Apparently now (I am using BOM 26.0.0, but I think it was available since some prior versions) you can ALSO setup your Firebase instance manually, instead of it being read automatically from the google-services.json.
If you dig into their code you can find overloaded methods for
FirebaseApp getInstance()
FirebaseApp getInstance(#NonNull String name)
Which you can setup manually using this overloaded method:
FirebaseApp initializeApp(#NonNull Context context, #NonNull FirebaseOptions options, #NonNull String name)
Being FirebaseOptions a builder class where you can setup your values manually.
I am trying to develop a Google Play Services like structure which is split into its own separate components (libraries) that can be added to Android Studio as dependencies. For example what is displayed below;
Like the Play Services libraries I would like to force the user to use the same version for all the libraries when adding more than one, as seen below;
I am wondering how the build.gradle file determines this? Is it built into Android Studio, is it coming from the build tools plugin?
As I would like to do something like this, if anyone has any helpful suggestions/links it would much appreciated.
You can use Lint to define custom rules based on your needs.
There is a really good explanation on topic with an example on Android Studio Project Site.
An easy way to start defining your own Lint rules is by modifying the sample project provided at this link http://tools.android.com/tips/lint-custom-rules/customlint.zip?attredirects=0&d=1
This way you will have all the dependencies set up to use the Lint APIs.
Source http://tools.android.com/tips/lint-custom-rules