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.
Related
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.
Google Play supports various 'test tracks' to allow test builds to be distributed to different groups through the Google Play Store:
https://support.google.com/googleplay/android-developer/answer/3131213?hl=en
Google Play uses the application version number to decide which apk should be delivered to the user from the set of test tracks that the user qualifies for.
Given that an apk can be promoted to different test tracks, is it possible to detect (within the Android application) which test track was used to deliver the apk? For example, is it possible to know (within the Android application) that the application was delivered through an alpha test track or a beta test track?
The motivation behind this question is to enable different sets of features through a server-side configuration based on the test track an application was delivered through.
It's possible to manage this through version numbers alone but knowing which test track an application was delivered through would make this process easier.
I was recently hired to rewrite an existing Android project. The old project was published to Google Play, but I do not have access to the source files or the certificate that was used to sign it.
I finished my project, but I'm unable to publish it as a replacement for the old version because I signed mine with a different certificate. Google Play is also complaining because I used a different package name than the original project.
Is there any way around these roadblocks?
It is a new application from GooglePlay perspective. So you can only publish it as new application
As you changed its package name....the only option you have to publish it as a new app on google play
It's a different app if it has a different package name; this is fundamental to Android. Package names are how you refer to a specific app in code and how you search for a specific app, among other things. If you want it to be the same app, keep the same package name!
If it is signed with a different certificate, it can't be installed as an upgrade. This is presumably so you can't install an app with the same package name as another app and read its private data — you have to delete the app (and its data) first (the benefit is limited, of course: you can uninstall the real app and install a lookalike malicious app and steal the user's data that way). This is a bit of a limitation in Android (it doesn't handle certificate expiry, for one) and might be fixed at some point, but I don't expect it to happen any time soon.
I've been in the same situation before — the original developer lost the signing key for one app but not the other. We changed the package name and released it as a new app.
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.
I have developed an Android app which is currently in an open beta phase, which means that each interested user can download the apk from the project's website (http://www.goodnews-mobile.com). I have already provided some updates through the web site and the users had the possibility to gracefully update their current installation without loosing any of the app's data. Now I want to release a new version of this app in the Android Market.
Here is the question: Will the users, who installed the app from the homepage be able to install the new version from the market without needing to uninstall the old version?
From a technical point of view I have ensured everything necessary to provide a graceful update (e.g. using a private key for signature that matches the market rules, maintaining version name and code in the manifest, etc.).
If you use the same key for signing your apk then your users will be able to update via Market. Just make sure it's not the test keys you're using (by default Eclipse uses the default test keys to sign apks before install them in an emulator).
Once you start using a developer key you can't use any other key to sign the same application (identified by the application's top-level Java package e.g. com.example.myapp).