I'm releasing an application in Play Console and there are multiple testing tracks that I can release to before publishing the application to production. I want my application to use a staging backend while it's deployed in the staging tracks, and once it gets promoted to production, the application should change its backend and use the production one.
The same thing happens with the google-services.json file that I've downloaded from Firebase to enable push notifications. I have two Firebase projects for the same application (one for development and one for production) and the application should to switch from the development Firebase project to the production one, once it gets promoted and released to production.
I thought this would be a very common problem among android developers, but I have found no information about it. Can anyone explain how this could be done?
Related
I've setup Firebase App Distribution on our projects with the provided "App Tester" android app which is amazing. Although I identified one major issue that I know a lot of people using this tool are experiencing and from what I saw, nobody actually knows the reason behind it.
The issue is : I download my app from the Play Store. Then I deploy a new version of my App on Firebase App Distribution to test it, go to App Tester, click on my app and click on install. I get the error "Installation failed" with no more details. To resolve the issue, I must uninstall the app from my phone and click install again to have a successful install.
The reason behind this is that Android does not allow a signed APK to be updated by another APK signed with a different key.
The APK that I download from the Play Store is signed by my CI but then it is signed again by the Play Store with their signing feature (can enable/disable it I know but I prefer to keep it enabled). The key used by Play Store to sign again my APK is private and nobody can access it.
But the APK that I upload on Firebase App Distribution with Fastlane is signed by my CI, not Play Store. So the key is different and that's why App Tester fails installing the app.
Can't I tell Firebase to do the same process of resigning my APK with the key used by the Play Store ? It is really annoying to uninstall my app whenever I previously installed it from the Play Store. More importantly, it's annoying for the testers at my company that don't understand why they get this error and don't know what to do...
Question: The application that you share with your testers using app distribution, does it have the same app Id (eg. com.xyz.abc) as the one on playstore?
There cannot be two signed applications with same app id on a single device.
One of the solutions will be to update the development app id to be different than production app id.
Eg.
Production app id - com.xyz.abc
Development app id - com.xyz.abc-dev
This will also enable both apps to co-exist on the same device.
I have a Mobile App for Both Android and iOS, both are built using Xamarin.
Android - The app is uploaded to the play store on the Beta Track and once testing is completed it is promoted the Production Track.
iOS - The app is uploaded to Test Flight once testing is completed a new release is created in AppStoreConnect, the build is set to the app currently in test flight and then set ready for sale (therefore showing in the Apple AppStore).
Is there a way to detect in the Mobile App if the App was installed from the Beta Track or Production Track in Play Store (for Android). And for iOS detect if the app was installed from Test flight or the App Store?
I also have 2 different WCF Web services that the mobile app connects to, one is the Beta services and the other is the Production services, these endpoints are hard coded in the app.
What I am trying to accomplish is when the app is installed from the Production Track/App Store then connect to the Production services endpoint, when the app is installed from anywhere else (i.e. Beta Track/Test Flight) then use the Beta services.
What I am currently doing is when the app opens the user is given the choice to pick between the 2. When it comes to doing a production release I remove this choice from the user and just make the app go to production only. I would preferably like the choice to be made based upon where the user installed the app from.
To be clear, the purpose of this is to build a single APK/IPA app that can be used for both Beta and Production.
UPDATE - There have been some interesting suggestions using the API to re-route the web services calls based on version number, but these still involve building separate APK files for Beta and Production versions of the app (which doesn't solve the question). As for what I'm trying to accomplish with Detecting installs from the Beta Track, it looks as though this is not currently possible.
I believe it's not possible as of now. But if you want to test your same android build against two different domain sets of API, you can make use of content provider approach. You can create a admin/utility kind of app, which will pass/update the domain in your original app through the use of content providers.
I followed the same practice in one of my product and its really cool.
Might be a bit late for you, but that answer can still help others...
It is possible to find the installation source on iOS as such:
#if DEBUG
// XCODE INSTALL
#else
NSURL *receiptURL = [[NSBundle mainBundle] appStoreReceiptURL];
NSString *receiptURLString = [receiptURL path];
BOOL isRunningTestFlightBeta = ([receiptURLString rangeOfString:#"sandboxReceipt"].location != NSNotFound);
if (isRunningTestFlightBeta) {
// TESTFLIGHT INSTALL
}
else {
// STORE INSTALL
}
#endif
I still don't have an answer for Android though.
I am new to firebase and android development, therefore, I have not totally understood how it works. I want to know if after adding project to firebase, does it mean the app is launched and will be accessible by anyone who have android or how do I tell someone to try the app when it has not been uploaded to playstore?
You are misunderstanding Firebase with Play store console. Firebase is a BaaS (backend-as-a-Service). In simple language Firebase is platform which allow to build web and mobile applications without server side programming language.
Adding your android project to firebase have nothing to do with publishing app. It will not publish your app.
Play store console is what that is used to publish android apps.
What is Firebase?
In a simple way, firebase as a server and many more log details related to your app and user behavior. It's a complete package to monitor app, users and many more. It will also give you scope to build app without having your own server and also no need of any language.
I want to know if after adding project to firebase, does it mean the app is launched
No adding project does not mean your app has been published or launched, but you can see crashes, save data, authenticate and can use available features in firebase.
and will be accessible by anyone
What you want to make accessible? If it is app, then it will be only accessible to users when you publish app in play store in production. There are some other options such as alpha, beta, internal test - each of these have some own functionality. Here you can add users email ids as tester and invite them to test or about your app. When you have not published an APK in production mood it won't be visible publicly.
how do I tell someone to try the app when it has not been uploaded to playstore
After adding firebase project nothing mean to release/publish your app. Publishing in play store does mean that. Here I will suggest you upload your app APK in play store ALPHA/BETA/INTERNAL test release mood then add/invite people to test your app.
We currently have a Play Store account with an application in production state. This application has a package name (com.foo.live) and it is uses the live environment.
Sometimes our customers asks for test versions of the application which uses different test environments - and having a different package name (com.foo.test).
Our main goal is to handover these test versions via Play Store alpha/beta state to UAT, but we can't upload the test builds to our currently existing app profile because the package name must be unique.
We are planning to create separated application profiles for these test environment applications but we are not sure is there any best practice for it in our current situation? This version will never be opened/live to Store users.
We are afraid of violation if we are using almost the same name. We are thinking about "App name Test" or "App name Integ" names but as far as I know Google will complain if we have test/integrational/etc. in our app name, and may violate for that there is already a similiary named app.
Do you have any experience/tips how to evade naming violations in our situation? (Maybe for iOS App Store where we are planning the same practice)
Why don't you add those customers who requires test environment in beta channel as a registered user?
You can create an app by changing only endpointt url to staging / testing environment and upload in beta channel and your customers can access this build , once your customer approves on this build remove apk from beta channel and upload production apk to play store.
I am currently having an Android application developed by an outside third party. We are at the point where we are ready to implement/test In-App purchasing, but in order to proceed with that we must upload the application to the market first (so we can make the In-App Purchase ID's). In order to upload to the Market, you must sign the application with a non-debug key.
My questions are:
What is the best way to go about this and maintain the privacy of my keystore?
Can the keystore be changed later without affecting functionality of the app?
What is a good back-and-forth process that would make this work, assuming I will not be coding the In-App purchasing myself?
It seems the best way to test the app is to have the vendor upload it to Market under a different package name and using a certificate that you and this vendor share. This would be the debug version of the app, which would not be advertised.
After testing and debugging are complete and you're ready to release the production version, you'd have your vendor deliver you the unsigned APK to you with the final package name, and you would upload it to Android Market using your certificate, which you never share with the vendor.
The keypair used for signing must remain unchanged, otherwise you can't update existing application in Market. Consequently right approach is that the developer gives you an unsigned APK and you sign it locally, then submit to Market.
As Bruno Oliveira suggested in another answer, for debug purposes you can create an application and sign it with the key shared between you and developer. But in this case be ready to create and submit a brand new application for release for the reason I mentioned above.