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
Related
I've come across a collection of android apps that utilise a questionable practice.
With the help of misleading ads user gets tricked into buying an app via SMS service (with prices up to 10 EUR). Afterwards the user then can enter an activation code in the free app distributed on Google Play store.
The entire operation is in grey-area, because it is the user itself who sends the SMS and is responsible for the cost. Due to the nature of the ads, its mostly unsuspecting older people that get tricked into this, because they assume that they must do it or they'll have problems with their device.
In app functionality being sold outside of the app store would most likely be a violation of Apple Store and the app could be reported.
I am wondering if there's similar rules for Play Store, so that this practice could be reported to Google.
The short answer is that Google allows this practice for now, but they are already working on changing it. From my experience, Google allows devs to use any payment/licensing model that their app requires. However, this is subject to change and the end results will be something similar with Apple's policy.
From their support page, it seems that from January 2021, they require that all new apps will use the GooglePlay IAP API. Existing apps have until the end of September to make the switch. As with any other policy, there are some exceptions, but please check the official page to receive the correct information.
I have an app that I want to be able to distribute to clients from other organisations. I don't want this app to be publicly visible on the play store, ideally the client would receive a link from me that would allow them to download the app from the play store.
I have had a bit of a search for this, so far I can only find 'Managed groups' (https://support.google.com/a/answer/2494992?hl=en) and 'closed tests' (https://support.google.com/googleplay/android-developer/answer/3131213?hl=en). A closed test looks to be along the lines of an ideal scenario, however the client would be aware that the app is in a testing phase, and may be able to do more with the app than intended for an end user. The managed groups also seem ideal, but they seem to be limited to my organisation, and when they talk about whitelisting that seems to be more whitelisting the apps on a user's device rather than whitelisting who can download the app.
Any help would be appreciated :)
To publish a private app within a client's organization (as a 3rd
party developer): If you’re an agency developer who wants to manage
the publishing flow on behalf of your client, or if you’ve built an
app for multiple organization clients and don't want the app to show
up in the public Play store, you can use your clients’ Organization
IDs to publish these apps directly to your client's organizations.
https://support.google.com/googleplay/android-developer/answer/6145139?hl=en
I work for a business that provides an Android app to multiple clients.
Each client uses their own EMM (Enterprise Mobility Management) solution.
I am attempting to ascertain what the options are for remotely configuring our app on Android devices using EMMs.
The configuration I need to deliver is an 820 character string containing a license key.
Not every device will require this license key, so will need to be set on a per device level.
The current method we use to deliver configuration to our app is to transfer a file to the device containing the configuration details.
This method works OK except: it’s a bit primitive; and one of our client's EMMs does not provide this functionality.
I understand that Google provides Google Managed Account and Managed Google Play Accounts API’s that can be used to configure devices.
We have ruled out Google Managed Account as an option because it requires the client to sign up to G-Suite which carries quite a heavy financial cost, and would be overkill just for being able to deliver a license key.
Managed Google Play Accounts could possibly be an option. It appears to require a one off cost of applying for a developer license of only £20, which is fine. Once the app is uploaded to the client’s private Google Play Store it looks as though it can be managed via the clients EMM UI, as long as it has the correct information in AndroidManifest.xml ( https://developer.android.com/work/managed-configurations ).
The Managed Google Play Account option could, potentially be the least worst option, but again having to introduce a dependency on Google services for a license key feels a but over the top, just not as over the top as using G-Suite.
Is there any other way, apart from the three methods mentioned above, of delivering app configuration to Android devices?
Based on my understanding managing multiple enterprises could be managed using https://developers.google.com/android/management/managed-configurations-iframe
Admin would have permission to manage multiple configuration files and devices on the console. We can also provision a device from the following strategy mentioned here https://developers.google.com/android/management/provision-device
You may also refer this link: https://developers.google.com/android/management/existing-emms for managing existing EMM's.
We have an Android app that we'd like to run on thousands of identical tablets that we will own and rent to our customers. The app runs in a sort of "kiosk mode" (we use app pinning, in the parlance of this page: https://developer.android.com/work/cosu.html). We're also, at present, configuring our app as the device owner using adb shell dpm set-device-owner ....
We have two goals here:
Be able to push updates to the app out to all our devices without any user interaction on each device.
Reduce the manual configuration of each new device when we unbox it and set it up as much as possible.
Can we use Google Play Store to push app updates out? I had in mind that we'd use the Alpha or Beta release for this and never actually publish the app for others to install. Using Google Play Store of course requires a Google Account to be added to the device, and once we do that, I fear our options for using a device owner app are limited, not to mention the fact that adding that Google Account may not be able to be scripted using adb or similar. We'd like to avoid manually adding the Google Account if possible.
Unfortunately the Google Play sandbox is still very consumer app oriented. However, the Play EMM API and Managed Google Play have some capabilities around distributing apps: https://developers.google.com/android/work/distribute
Their EMM documentation covers provisioning as well via either a device-driven flow (using nfc) or a user driven flow (using a google account): https://developers.google.com/android/work/prov-devices
Alternatively you could look at 3rd party MDM solutions or use a platform built for enterprise mobile deployment like Mason: http://bymason.com
Mason allows you to create a custom Android OS in a just a few minutes (kiosk mode app, disable camera/sms, remove apps and settings, etc). Applications can be bundled and versioned along with the operating system or deployed independently. Mason supports background app and os updates 100% controlled and configured by you.
You can order large volumes devices from Mason with your OS and apps preloaded on them as well.
Feel free to ping me directly: dylan # bymason.com
Big Disclaimer: I work for Mason
I wrote one kiosk mode device owner app. Since it was a system app, we just had it use the system ability to do silent installs, self hosted the updates and checked for updates on a regular schedule. No configuration needed. I think you're more likely to hit legal problems than anything else- are you really using high end tablets that have legal licenses to Google Play for a kiosk mode app? Or are you using the cheap tablets from China? Remember that Google Play is not a free app- there's a licensing fee and usage agreements you have to sign to have the right to distribute it. The cheap tablets tend to just illegally sideload it, or not have it.
Advantages to doing it ourselves: we had absolute control over rollout, there was no company saying when we could send updates, and no way for the user to reject/not download an update. As you scale you could have even used more intelligence, and done rolling updates to the fleet via push notification.
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.).