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.
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.
We are using Google Play Alpah testing tracks which can be tested by different testing teams for their respective modules.
But the links generated by these tracks are same how to get an application for a member which may be added to multiple closed alpha testing tracks.
e.g. We have two tracks Alpha Track 1 and Alpha Track 2, we have few common tester emails in these two but most of them get the apk from Alpha Track 1 which is the first created track. How can they install apk from Alpha Track 2 from their testing email accounts? Or do they need to have totally different email id for each track?
Google just updated their help center documentation regarding this. See Version codes & testing track statuses section (emphasis is mine):
Version code requirements
Users receive the version of the app that has:
The highest version code that’s compatible with their device, and
Been published to a track they're eligible to receive
All users are always eligible to receive the production track. If an APK with a higher version code is published in production than in the test track where the user opted in, the user will receive the production APK.
Users eligible to receive multiple tracks will receive the highest version code APK published on those tracks.
For a user to be eligible to receive a test track, the user must:
Be included in the managed track configuration, and
Have opted in to the corresponding test program
For example, all users who opted in to the test program are eligible for the open test track. Users who opted in to the internal test program are not eligible for the open and closed test tracks, even if they're included in the managed testers configuration. These users would not receive higher version code APKs published on those tracks.
For more information, learn about versioning your apps.
Hope this helps.
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.
This is the Android version of App for limited or restricted audience
The project
I'm going to start a brand new project for one of our customers that will be deployed to our customer's suppliers to track on-field activity. I am skilled enough on Java/Android development so this question is only about deployment.
Owned vs provided devices
Our customer will either provide a Samsung Galaxy Ace 4 device to the suppliers or will allow the supplier to use their own Android 4 smartphone without warranties from us. Our customer currently has a Google for Business organization set up, but we cannot rely on that (see partial answer).
Technical (non functional) requirements
Ability to easily distribute application and updates across enterprise users.
Application should not be visible to the public
Application must be able to send crash reports so our team can inspect and investigate
The question is
Given the above "should not be visible to the public" statement, what is the most effective and efficient way to deploy an Android app targeted only for enterprise users?
I'll post a partial answer below. I'm asking others to enrich it with other possible means, including using Alpha/beta channels for which I don't have experience about
Currently, limited-audience Android applications can be deployed like this:
Publishing on Google Play as a free app for the public
Maybe adding a limitation to our country
Advantages:
Simplemost and well documented
Auto deployes updates as soon as no new permission is enforced
Collects crash reports on Dashboard
Disadvantages:
Everyone can download the app
This has the disadvantage that some organizations may not be happy as publicly available code might in some cases help exploit vulnerabilites on remote systems (but it is almost impossible if app is well-written and obfuscated)
If country limitation is enforced, imported devices won't download
Distributing the APK direct URL
Advantages:
The app remains private (enterprise users are surely not going to redistribute the app to friends as it's no use without enterprise credentials)
Disadvantages:
No crash reports unless implementing a third-party library
No auto updates unless implemented by custom code or third party library. Implementing auto updates prevents the app from being published to Google Play in the future, even on a private channel, as Play prohibits apps that auto-update themselves via third-party channels. Or, to be precise, the auto-update feature and Play publishing require, in order to exist together, maintaining two APKs
Google Play for Enterprise
As mentioned on this link, Google Play provides a private channel for app deploying for users withing a Google for Business organization. This is the perfect approach for applications that organization's users must use
Advantages:
Same as publishing for the public (simple, auto update, crash report)
Visible only to restricted audience
Disadvantages:
Every device must come with a Google account within the organization, and it will be economically unfeasible to [request the Sysadmin to] enable Google accounts for every external supplier in our target organization
Permanently in Alpha/Beta
I haven't tested this yet, as it is also very tricky. Basically, it involves using testing mode without ever going to production. With Google Play, one can deploy artifacts into Alpha (e.g. test server environment) and Beta (a trick to point to production server environment) without ever moving the app to Google Play's Production stage.
All requires setting up special moderated Google+ groups
Potential advantages:
Same as publishing to enterprise
Disadvantages:
Only telling users to subscribe to Google+ and joining a community
From your requirements, I would suggest distributing the APK via a direct URL and integrating a service such as HockeyApp (see their Android SDK for more) to manage both the crash reports and app updates.
"Ability to easily distribute application and updates across enterprise users"
Many services allow .apk files to be uploaded directly to their service for deployment. A direct download link is then generated for that build.
Crash information is collected and updates are automatically displayed if the app implements the Android SDK provided by the service.
"Application should not be visible to the public"
Services such as HockeyApp do not publicise direct download links publicly. This link can therefore be distributed as required.
"Application must be able to send crash reports so our team can inspect and investigate"
Full stack-trace and device information is sent along with crash reports and can be viewed online by technicians.
From my experience there are a few pros and cons:
Pros:
App distribution is super easy, as simple as visiting a website.
Bug reports are comparable to those received through Google Play
Cons:
Crash report's aren't sent automatically and updates aren't automatic
By default, updates and crashes appear as system dialogs prompting users to either send the crash report/update the app or cancel. Ideally, no user interaction should be required to perform the desired actions. I am sure it is possible but have not found relevant documentation for it.
Cost. These services aren't free.
Would require the removal of the service SDK from the app if uploaded to Play Store
I have an app which is planned to be released in several phases:
Testing phase using email distribution to small testing population (in-process).
To a small group of users. It will be a diverse group geographically and it is important that the app is not given / spread to wider audience.
For broad distribution to who ever might want it, free or paid (logically google play).
Given this, can the Google play licensing scheme be used to facilitate the first phase? I read in the following link that google does not want any form of selective distribution (other than testing). I did not see any references for selectively enabling an app (second link).
How i can offer a licensing Android application
http://developer.android.com/guide/google/play/licensing/adding-licensing.html
The alternative for phase 1 would be to develop an authentication mechanism with a server using a distributed key. The key would be matched against either a uuid or google id on a server before the app could be activated. Distribution to new users would be involve providing a new key.
Comment appreciated on both.
The Google licensing scheme (LVL) only works for paid applications. What it does is basically check that the current app is in the history of purchases associated with a particular Google account. If it is, you have legitimate paid user; if not, well, something went wrong, or somebody is trying to pirate your app. It has had mixed success. It doesn't allow you to control who can use your app in any other way.
So if you want to distribute a private beta, you can either:
Distribute directly via email, etc. (first phase)
Host on Google Play and develop your own activation scheme (product code, etc). Then only the people who receive the code can actually use the app. (phase two)
(1+2) Distribute via your web site to anyone, but require activation. (phase two)
For 2., you are bound to get some 1-stars from people who don't read the description/instructions ('Doesn't work', 'Activation required, boo', etc.), so it is a good idea to use a separate package from the final one (com.myapp.beta, etc.).