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.).
Related
I am currently evaluating a mobile developer that I met online. He sent me a list of his published apps and there are a total of 33 apps in the list, mostly Native with a few in React Native.
The weird part is that every app I’ve checked so far has a different developer name and none of them match the personal name of the developer. (Yes, he could publish under a business name but one of the apps is (C) Aston Martin.)
Am I reading too much into this or is it actually as fishy as it smells?
To answer your title :
Yes, it is possible provided the publisher have enough resources.
There might be a few reason for a developer to publish the apps under different names/developer/publisher.
The apps are developed for different clients, thus they would want to separate out the publishing to store (PlayStore or AppStore) part, so that when the clients decide they want to use the services of other publisher etc, the current publisher could just hand over the accounts related to that client. Such as emails, store accounts, hosting accounts, and possibly even bank and credit card account which could have been made under the client's company name to begin with. And it also allows the clients to handle the informations of the Apps at the store themselves easier.
The company, for one reason or another does not want the published apps to be easily traced back to the same company. Maybe because of tax-evasion, privacy issues, or simply because the content of the apps is not totally legal to be distributed in the country where the developer is operating from.
But considering your description of "evaluating a mobile developer that I met online." There are a few possibilities that the apps are published under different names
The apps are build while he is working under different companies.
The apps he listed are apps that uses one/few libraries that he made.
He was working under freelance jobs for company(ies) that in the end developed the apps for those companies published separately.
He was simply lying that those are his apps to get your approval, since you can't really trace back so many step without a legal court request to the store (PlayStore and AppStore) to know that he is really the one developing it.
One easy way to validate for PlayStore is to have them send you an email (or a few) using the registered email address at the bottom of the PlayStore listing page of the apps for one or few of the apps.
For example Facebook Lite's would be lite-android-support#fb.com.
But if they are working under another company, or such, they would not have access to the said email address, and you would have to ask them to provide other ways to validate their relations to the projects listed.
I'm developing a pay for win Android app, in which users are, among others, ranked according to the amount they have spent. The payments are Android in-app purchases.
My questions are:
Is an authentication system required for my users, in order to purchase and be ranked? In other words: instead of using an authentication system, could I use the UUID of the phone, or its MAC address, or any other piece of information that would actually act as an authentication system? If yes: why isn't there any other Android app that proceed in this way (indeed, they use Facebook/Google authentication, or e-mail + password authentication, etc.)?
Is there any Java ranking library that I could use and bind it to the Android in-app purchases? In particular: does Google offer such an API?
Is it a good idea to use Google's authentication and ranking based on Google Play? The ranking criteria must also be the total spent amounts.
Authentication and authorization
Firstly, I would like to make the distinction between authentication and authorization.
Authentication is a way to determine a user apart from other users. Authentication allows a developer to identify Jane Doe as a separate entity from all other users. Authentication is often a precursor to authorization.
Authorization pertains to what actions a user can take on particular resources. Authorization deals with the what, when, how as opposed to the authentication that deals with who.
To state your questions using more definitive language you are asking for best practices relating to:
Authenticating a user inside an application that is available on the Google Play Store, and
Calculating totals related to Android's In-App purchasing, and
Authorizating a user to take a claim action on a prize entity depending on the aforementioned total aggregate
Recommendations
I would highly suggest you use Google's OAuth 2.0 service to authenticate users as opposed to building your own authentication framework or implementing any other authentication framework, especially if this application is only used within th Android ecosystem. I recommend this because:
Android users already have a Google account, and
Implementing your own authentication framework requires very niche skills which usually require a team of people, and
Google already offers an Subscription and In-App Purchasing API which can be queried to rank you users, and
You will already have implemented this API to support in app purchasing to begin with
I would highly suggest you do not use MAC address or UUID authentication because
On a rooted phone I can change my MAC address, and
It does not uniquely identify a user across multiple devices, and
Using this type of authentication would not provide any benefit to your second goal of authorizing actions based on a total aggregate
In other words by using Google's authentication mechanism you can not only uniquely identify users across multiple devices, but you can also leverage the in app payment system to build your particular authorization logic.
The In-App Purchasing API already contains the necessary information you want since you will need to implement it to support in app purchasing to begin with. You might as well use it as a basis for ranking since it is readily available, secure, and contains the information you need with well documented ways of accessing it.
Additionally, you may want to look at the promotional capabilities and one time product-specific billing features functions and related APIs. This might fit your use case and it may make your application more secure and standardized.
Using the provided authentication framework and in app purchasing capabilities standardizes your application up until you implement the claim your prize functionality. People enjoy standardization because they become familiarized with it, and it provided a level of trust, so I would definitely investigate the other aforementioned APIs to see if your prize idea can be based off a foundation provided by Android. This would standardize your app all the way through and, in my opinion, would be best practice.
Summary
I would provide some sample code but your questions are still a but high level to provide anything useful in the way of code snippets. To summarize though my recommendations are as follows
Leverage the Google OAuth 2.0 framework for authentication, and
Leverage the In-App purchasing API and related APIs as a way to calculate total and rank users, and
Investigate the promotional capabilities, or one time product-specific features already provided by Google to see if it fits your use case, and
Avoid using MAC addresses and UUIDs for authentication for the reasons I outlined above
Edit ....
After rereading your title I realized I glossed over the fact that, as I understand it, the term ranking and it's related functionality as used by Android is mostly centered around where you application sits, popularity wise, in comparison to other applications. I have not seen the term used by Android to refer to internal ranking of users against some developer-defined criteria ( total, in your case ).
I'm not saying it does not exist, just that every time I see ranking it refers to application popularity. Therefore I would refrain from using that as a query term when researching how to build this application as you will likely get a plethora of false positives.
What I think you want, to reiterate, is
Authentication
Calculating in app purchasing totals
Promotional or one time features based on that total
Those terms will suite you much better. Please feel free to start a new post when you get further in to the project if you need assistance consuming the APIs
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 am working on an app that would require an activation code in order to be used after being downloaded (user will get the code by postal mail). I understand that Apple will be rejecting the App, but can someone confirm if that functionality (activation code for an app) would be valid for Android? And that it could be used.
Before building up a prototype I would need to confirm this fact.
Anyhow, I will limit the audience of my App to Android users as I see that I have no options with MAC.
You should read the Google Play Developer Policies as your starting point (in particular the section "Paid and Free Apps").
If you are using activation codes to bypass app payments or in-app payments, you will be in violation of Google's policies. If the activation code is an integral part of your app's functionality (for example you are sending it by post to verify a user's address) then you should generally be okay.
Disclaimer: I am not a lawyer.
I was using an app once that was later pulled from the Play store because you could purchase some premium features over PayPal (without Google Play). If you intend on charging for this code it might and probably will be an issue, however, if you will distribute the code free of charge to select customers it might work.
But, a better way of doing it would be with a Google Play group. You'd mark your app as beta and make a test group, that would only include the people you want.
But if you want to limit your audience there is really no reason to put your app on Google Play, just distribute your .apk file through your website, and have a serial code as a backup.
I am in the early stages of scoping an app that targets a specific vertical market. It is not consumer orientated. The organisation developing the app has existing web-based products and established infrastructure for registering user accounts and billing for those products, and the app should inter-operate with these products. To that end, I have a few questions:
1) If the app that has functionality that can only be enabled from outside the app (for example, via a separate web site) and where the developer bills the user for doing this:
Q1. Can this App be distributed using Google Play?
Q2. Since enabling the functionality takes place outside of the app, does the developer have to use Google Play's payment system to bill for it?
2) If the app which allows a user to create an item of content on a separate web site, so that they can subsequently modify it on that site and be billed for doing so (eg, a bug tracking app that charges for creating a bug record on a site):
Q3 Does this count as an in-app purchase and require use Google Play's payment system to bill for it?
Where can I find definitive statements from Google on these scenarios? I am only finding material that relates to consumer applications where the purchasing and billing scenario is fairly simple.
I cannot shed much light on the potential "thou shalst not have any payment methods beside me" aspect of your question, but as per the technical side, the following aspects come to my mind.
Q1: Technically, the app could either be free on GP and use other payment methods, or it could use the Licensing Validation service.
Q2: The only secure way of deploying Google Play Licensing is to perform all integrity checks on your own secure server. The app could request the GP LVL info and pass it to your server. You could use the GP LVL user ID (an obfuscated binary app-specific byte string) to identify the user and negotiate with your app any password details you may want to implement. Of course, in this scenario, I would expect the user to feel like he already payed so the registration on the server side should be smoothly integrated. If an "enabling"/"authentication" step is additionally required on the server side, I'm not so sure I'd use the GP LVL.
Q3: You could use GP IAB V3 consumable in-app purchases for this (or V2 subscriptions but it sounds more like a per-item payment). Again, this is only secure if you generate a per-purchase developerPayload for the buy Intent on your server and validate it when the app looks at the user's purchases. Validation again must take place on your server, or else you'll have to include your app's public key in your app, which is a major step towards your app getting cracked.
In general, if you have a user management of your own which is to be used, it is important to know that the GP info is relatively anonymous (LVL: obfuscated, IAB V3: no info in the direction of the app at all). So a reliable, use-case oriented binding between "your" accounts and the GP experience would be key here, I'd say.