I have an Android app containing 10 different app flavors, and I need to send push notifications targeting specific flavors. I got it working with one, by using google official support documentation - using the file google-services.json on the root of my project.
I know I will need one google-services.json file per each of the flavors (since they're in fact different apps), but the issue comes on where to put those different files, since this needs to go to the root of the project and not to the root of each specific flavor.
Anyone has had a similar issue before and found a way of handling it?
Related
I'm working on an Android app that uses Firebase for a few different functions. I'm currently trying to expand from a single Firebase project to 3 to represent development, staging, and production environments.
All of my projects need to use the same bundle ID because of a restriction by another tool I'm using (RevenueCat). What I'm noticing with this setup is that, even when using different google-services.json files, I'm always pointing to my original, production Firebase project.
I've searched around and seen some things about needing to add SHA-1 values on Android to differentiate the apps. I've tried adding the SHA-1 from the app signing key certificate in the Google Play Console to the production project and the SHA-1 from the ./gradlew signingReport output to the staging project. Still no dice, unfortunately.
Does anyone have experience with this kind of setup or any other ideas to try? Thanks so much!
In this case, it turns out I just needed to clear out the app/build folder. Apparently the Firebase configs get "cached" in some way between builds, so clearing it forces it to use the new configuration.
I've just added it as a step in the build process. After this small change, everything is working as expected.
Having several different apps inside one project with the same bundleId/packageName is impossible. You have the possibility to use one google-services.json for several apps, though - you just need to add several apps to your project. The packageName/bundleId of those apps should be different, though.
It is very usual for your case - splitting the app into several flavors to have an appId suffix. For example com.example.app.prod, com.example.app.stage, com.example.app.dev - the suffix can be configure in the gradle.build for each flavor. The issue is that you will have to have different apps inside the firebase project or different projects for each flavor - depending on your needs. For example, when the apps are part of the same project, they will share auth and database storage but will have separate crashlitycs, etc. The different projects will have everything different.
SHA-1 is a bit different thing - it is meant to limit/enable/disable the usage of the APIs based on the signing certificate. There may be several SHA-1 for the same package name. Moreover, SHA-1 only works for Android apps.
What you can do is to create several projects - one for each flavor and register the app under the same package name inside each one - you are able to do that! Each flavor will have to have its own google-services.json file in the appropriate folder.
It works really well with the different package names.
I have never tried this approach with the same packageName, and I don't know the possible drawbacks, so I assume you may face some issues. Or not.
In most of the cases, a simple configuration using google-services.json will be enough for having different Firebase environments in your App. But as we saw, things can get complex very quickly, and depending on the requirements custom ways for configuration and initialization of the Firebase services can be needed. I this article I tried to summarize the different approaches for achieving this goal and share my personal experience. I hope that it was helpful to you and that you enjoyed it.
I have an Android app handling notifications through IBM Bluemix. I created a google-services.json file, added it to the project. It works like a charm.
But now, I want to deploy a generic version of the app to the store. That application will serve different customers, where each customer has to create his own Firebase project and Bluemix account. When initializing, the application should read the necessary ids/secrets from a server instead of getting the values embedded statically in the app.
I saw that the google-services.json file is a convenient way to generate resources in values.xml, but I didn't find how to have these values set dynamically at runtime. Any idea?
i have two projects in android studio. the first one is called "test1" and the second is "test2". i want to use google cloud messaging to communicate with each other. my question is, do i need to use the same "google-services json file (downloaded from google website) on both projects, and also the same project id?
or use diffrent google-services files?
you have to use two different json files, because first project package name and second project package name are different. Google will generate server key depends on package name.
I do not understand the communication word between two different projects. (You mean example to say Facebook send push notifications to Twitter ? )
If you have two different Projects, Yes you need two google-services.json files because both projects have different package names and Sender-ID(i.e Project ID in google console )
If you want communication between two application's (not two different projects), then you can simply use ONE google-services.json file
Note: With out google-services.json file also Servies works well in production but not after releasing your app in public.
Also read What is google-services.json to get clear idea of it.
Is there any way to make my app "aware" of where it is downloaded from?
To clarify, they will not be going through the app store, they will be downloading the actual apk or plist (I think .plist is the extension for iOS?) file directly from my website.
Background
My situation is: You go to my company website, you get involved with one of our contractors, and you download our app from our website. However, depending on which contractor you have a relationship with, the app is branded with different UI elements specific to that contractor. I want there to only be a single app, but when you download it, the app is "aware" of which contractor you downloaded it from, and then uses some logic, (likely calls to a webservice, but the implementation of that is not important here) to display branding specific to that contractor.
I am trying to do this for both android and iOS, so solutions for both or either one would be appreciated. I want there to just be a single app (1 for iOS, 1 for android) because it is not desirable to create a new app everytime we get a new contractor, and because we would only want to have to register 1 app for push notifications.
Asked before
I realize my question is a duplicate:
It is essentially the same as this question: (One iPhone app with different template based on the URL it was downloaded from)
I want to give my iPhone app to different distributors for
distribution.
When a user will download the app from one of the distributors and
open it the app should connect to our servers and ask for the unique
settings of this distributer.
The question is, how each app can "tell" from which distributer it was
downloaded from?
I don't want to compile a different application for each client.
I am reasking it because the answers were unsatisfactory and did not at all address the issue, and the question is old (over 3 years old)
The first answer:
Do you want an app or iOS WebApp? if you want iOS app, I do not think
you can distribute to other distributors, because Apple is the only
distributor of iOS applications, so all the downloads come from there.
if you want a WebApp, you create a download link redirected to your
webapp to read the link to the server it pulls everything you need,
layout, information, etc ...
They completely missed the point, it has nothing to do with the question. The second part explains how one would get the different UI elements, but does not answer how the app is aware of which UI elements it should be requesting in the first place.
The second answer:
I did some research into this and the only way I found to do it is
just to create different targets for each app then share the source
code across both the apps, but this still means that you would have to
do two submissions still.
This does not answer the question either: AFAIK, multiple build targets help to have a single code base, but you still would be maintaining multiple apps, not a single app.
For Android, for a self-distributed app, you have two main options for creating "branded" editions of that app.
One is to use Gradle product flavors, where you create one flavor per contractor. Each flavor can have what amounts to an "overlay" sourceset, where you can replace stock resources (strings, icons, colors, etc.) with ones for that flavor. When you build the app (Android Studio, CI server, manual command-line builds, etc.) and have it build one or all flavors, you get a per-flavor APK with the per-flavor resources. If, at a later point, you elect to have per-contractor application IDs (so N contractors' apps can be installed at once), making the change will mostly be a matter of adding one line per flavor to your Gradle build file (identifying the application ID for that flavor) and updating your GCM API key for each application ID.
The older approach would be to change files in assets/ of a standard APK to make a branded edition. This approach is aggravating, as you can't take advantage of Android's resource system, and you have to arrange to re-sign the modified APK, but it will work.
In both cases, you have dedicated APK files per contractor, so you arrange for your download link to point to the right one for the contractor for this particular customer.
The com.android.vending.INSTALL_REFERRER solution probably is not a great solution for you. Besides the dependency on the Play Store, your app would have to have branding for every contractor "baked in". Certain elements (application icon, application name) cannot be changed at all and would have to be the same for all contractors. Other elements (launcher icon, launcher name) could be changed, but on some devices will take a reboot to take effect. And if you don't ever get that broadcast, or it is not for a recognizable referring URL (e.g., the user just found your app in the Play Store and installed it), you're in trouble.
Recently I came across a few apps (such as Clockworkmod's Rom Manager) where in order to get the pro version you had to download another APK. However once this APK was downloaded Rom Manager automatically knew this APK existed and added new functionality's. For example another app is the Astro app in which you can extend it by downloading modules from the Market.
Now I know how to check for the existence of another app, and I also know how to interact between apps via services. However my question is,it seemed like Clockwork and these other apps are using different apks for a plug-in type architecture. How does one do that? Have they predefined an entire plugin architecture and service model so whenever a new apk is installed the main app can check if its a module and call commands on it? Or is there something else going on?
I think these apps just know their plugins and how to use them. Plugins are separated to save some space or to add paid functionalities to free apps. Note that there are no 3rd party plugins to these apps - all of them was created by apps authors.
Actually I think it is technically possible to create real plugin system for Android apps. You could search for installed plugins using broadcast receivers, then talk with them through some API. However adding extensibility through plugins isn't trivial task, so I don't think it makes much sense to create such apps for mobile devices.