I'm trying to build a library allows users to receive Firebase notifications from our server, while still allowing any third-party developer to set and receive their own Firebase notifications.
I'm struggling with how to do this, especially on the console side. I know you have to register your app's applicationID (project name) with the Firebase and then you receive a google-services.json file to add to your app. How does this work with multiple apps with a different package name for each? In my Firebase console, am I continuously adding the project name of each app that uses my library. That doesn't seem right. And how does the google-services.json file handle multiple senders, and which sender generates it?
I'd appreciate any insight from someone with experience in this area.
What you're trying to do is not generally supported by Firebase. The only supported use is at the application level, not for reuse by other libraries.
That said, some of the features can be used this way if you're willing to initialize them directly in code rather than using the google services Gradle plugin. For example Realtime Database can be programmatically initialized by calling FirebaseDatabase.getInstance(), and you make sure that you're also initializing a dedicated FirebaseApp object to pass to it.
Each Firebase feature has its own static initializer like this. However, if it requires a Context parameter (as with Analytics and Remote Config), you won't really be able to use it safely from a library, because it has no way to separate usage between different components within the app.
For more details, also read:
How does Firebase initialize on Android?
Take Control of your Firebase init on Android
Related
What I'm trying to do - is to separate all the account management routines in a separate .aar library to use it in all of my project. The point is to share same account between different apps.
For example: I've logged in to the app A. App A saved some auth data to the Account manager. Then I install app B that has same AAR with account management. App B automatically use credentials created in app A.
For the first simple try I assembled all "kind-of-CRUD" methods for AccountManager in my AAR. I've also added AuthenticatorService and Authenticator classes in that AAR and added my service with authenticator.xml inside AAR's manifest.
The problem is that app, which is using my AAR to authenticate, can't create Account.
I've keep getting the "uid XXX cannot explicitly add accounts of type: com.example.acc_type" exception.
I've double-checked, and account types are same in authenticator.xml and in my code.
What is more: if I will move the AuthenticatorService, Authenticator classes, authenticator.xml and the Service description from the AAR to the app - everything is working fine!
So I believe that there is some mistake. Is it really possible to have AuthenticatorService and Authenticator in aar library?
Technically speaking, keeping your AuthenticatorService and the Authenticator classes in a separate Android-Library module for the purpose of reusability should not cause any issues while using it in an android application. What your issue is sharing data between two applications and not multi-modularity. For that you can create a shared local database either using 3rd party libraries or flat files (Whatever suit your needs).
Android provides some useful API that allows IPC for android applications:
If the size of data is small then you can use the SharedPreferences API for that, however it puts a CAP on how much data an app can contribute. As SharedPreferences is Global in nature, i would not suggest storing sensitive data there.
If you want an app to expose some data, then look into how android architecture allows an "Export" directory inside every app where you can store any data and other apps can simply read it in a safe manner. Deleting an application will clear all of the data present in this "Export" directory.
I ran a security test via the ImmuniWeb tool on my Android app APK. One of the observations the tool made was that one of the app contains hard-coded sensitive data. It further said:
An attacker with access to the mobile application file can easily
extract this data from the application and use it in any further
attacks.
There is 'google_api_key', 'google_crash_reporting_api_key', and
'google_storage_bucket' found in file
'android/res/values/strings.xml'
The issue is that this strings.xml file is auto-generated and cannot be edited:
How do I clear this issue?
The data you're referring to is not "private" or "sensitive". This is a standard configuration for Firebase products that get injected into your app as part of a standard app build using the Google Play services plugin. All of those values are just identifiers for Firebase and Google services that need to be known by the client in order to address those services. Without them, your app wouldn't know where to go for information.
If you're using Realtime Database, Firestore, or Cloud Storage in your app, you should be using security rules for each for those products in order to limit who can read and write which locations in those products. That's how you implement security in apps that use Firebase. Trying to hide or obfuscate the configuration isn't going to foil a determined attacker.
I don't know anything about this tool you're using for this security scan, but it doesn't seem to be aware of these facts.
I am looking for the most convenient way to log entries from my Android application to Stackdriver. My code is in Kotlin using the Flutter framework.
I am already using logback-android due to its usage by a library I'm dependent on, so a SLF4J appender to Stackdriver would be most suitable but I couldn't find anything like it. I also tried using the Google Cloud Logging Library but it seems to not support Kotlin.
After a day of thinking about this issue, and due to the fact that a service account shouldn't be located at the client-side (the Flutter app), I realized the best way is to implement a \log endpoint at the server-side and send logs using authenticated requests.
I wonder what is the main purpose of creating different applications under same project in firebase console as it does not allow to have different package name. I need separate package name for around 20 mobile applications in android for push notifications(google-services.json). Can somebody guide me how to do that in FCM under same account(gmail).
Thank you.
Different applications in one firebase project can (or must?) have different package names.
If you want to use push notifications, they will all have the same server key. But you can filter on package name or registration token so it's definitely manageable on your server side.
Alternatively you could make multiple projects, one for each. But note that there is a project limit you might hit. This limit is not the same for everyone, based on account activity and such, and you can request more projects when you reach it.
for ex: generally if we develop any app in 3 different platforms
like android,iOS,windows.
we have to create 3 different applications in single project.
then only firebase data will sync and push notifications will work.(server key/project id should mentain same)
I'm currently using Google Play Services v6.5.87 within an established Android application and GCM & push notifications are working well.
But as part of upgrading to current versions, I have seen that GCM uses a different process - eg creating the new json configuration file etc.
So, before I go and upgrade by creating this new json configuration file etc, I'm wondering what will happen to the existing versions of the app on the current (or older) builds if I do this? Will they cease to work? Do I need two separate GCM streams??
The new APIs should be essentially a drop in replacement for the current ones.
Use InstanceID.getToken() instead of GoogleCloudMessaging.register()
Add the GcmReceiver to your manifest instead of writing your own BroadcastReceiver
Extend the GcmListenerService class and override the corresponding methods instead of extending IntentService.
You should be able to skip the early steps in the guide and only follow the ones from here on.
The json configuration file is not required. It is meant to streamline the integration of Google services, and includes the sender ID so new apps don't have to manually add it in.