I'm designing an API for an Android app. An iPhone requires a user to get an Apple ID, do Android mobile devices in the same way 'require' users to get a Google ID?
Ideally I want to be able to assume that users downloading our app on Android will have a Google account, so that we authentication via the Users and OAuth APIs is a snap.
You're not required to have a Google account associated with an Android device, though most people probably do. You do need one if you download apps through the Market, but you can also side-load apps, use other markets like the Amazon App Store, etc.
For both the Android phones that I've bought in the US (an HTC G1 and an HTC G2) it has forced me to enter my Google account information (or create a new Google account), before I could do anything on the device (similar to how the iPad forces you to connect it to iTunes before you can use it).
Some people suggest clearing the data associated with all the Google apps on the phone to disconnect the device from the Google account, or you can just remove the account through Settings -> Accounts & Sync.
I suspect it boils down to exactly how the carrier delivers the phone to users. If you want your app to be available globally then you should assume many users will NOT have a Google account.
Generally, users need a Google ID to use Android Market. As far as I know, they do not need one to use other markets (such as Amazon). What are you authenticating?
Related
We have a G Suite account, and I would like to manage some of our company owned tablets as kiosk displays using the Android Management API. However, it seems to require an arbitrary "personal" Gmail account, instead of allowing a G Suite user to use it.
To provision a device, you need to create a policy. A policy needs to be assigned to an enterprise.
Option 1: Trying to link an existing enterprise
You can get your G Suite Organization ID from here, and this ID is apparently also your Enterprise ID. The API needs it in the format enterprises/id, e.g. enterprises/abcdefg
Unfortunately, even after authenticating with a super-admin, any calls to the API are met with
{
"error": {
"code": 403,
"message": "Caller is not authorized to manage enterprise.",
"status": "PERMISSION_DENIED"
}
}
Option 2: Creating an enterprise
A Quickstart Guide is available that makes it easy to create an enterprise, create a policy, and then provision devices. Everything works well when we use a personal Gmail account and I could successfully provision a tablet into kiosk mode. As soon as I try to use a G Suite account, I am met with:
"G Suite is not currently supported by managed Google Play Accounts, please choose a non-G Suite account to continue."
Do we need to create an arbitrary Gmail account (e.g. ourcompany-devices#gmail.com)?
What happens if we then later wanted to provision devices of third parties? Would everyone's devices then be linked to an enterprise of an arbitrary Gmail user?
Any help would be appreciated, thank you.
We did option two. However this means that you cannot put something onto the private play store.
Android Management API is currently not compatible with GSuite.
You need to use a Gmail account to create a Managed Google Play Enterprise in order to use Android Management API.
If you plan on provisioning devices for third parties, it is suggested that you create a separate Enterprise for each in order to link each device to the intended enterprise.
You can read about Managed Google Play Accounts here
I've published apps to our internal 'enterprise' and also to our pseudo-enterprise (option 2).
I don't think there is any other way unfortunately. Just make sure the gmail account credentials are very secure and I think it is reasonably safe.
After doing option 2 you do get an organization ID. One thing that isn't mentioned in the documentation is that things don't happen instantly and much of the process is poorly documented. I spent hours searching up solutions for issues I was having and the solution ended up being I just needed to wait a few hours.
If you are publishing first-party applications on Google Play you can make them available as private apps to both your internal enterprise and the pseudo-enterprise.
There are many online payment applications such as paytm, phonepe, Google pay.we do have different referral programs in these respective payment applications. After signing up for an account in the device when we try to create another account in the same device by clearing the application data, we are not getting any referral bonus. How do these apps know that the respective mobile has already used for the application and its not eligible for the referral program?
As far as I know Google pay encrypts and stores a unique device account number on a dedicated chip on your device. And probably also it saves a Unique Device ID for each devices that installed Google Pay.
FYI: You can link two banks accounts on Google Pay if that is what you want.
I have a app that the ambition is to be executed on multiple devices on the same account. The problem is that it payments must be made by per amount of devices it is installed on. Or a Payment like 1-10 devices, 11-20 devices.
At the same time, the ambition is to be able to use Google Play to make it possible to push out updates on the app to all devices at once. But that is in conflict with the Google Play's terms of payments.
I only found how to restrict the app on some devices, but not how to make it possible to take payments per device.
Limit (Restrict) app installations per account (detemined by unique devices) in Android
Are there a solution to make payments per device, and still use Google Play, or are there any other solution?
In iOS, we have provisional profiles to setup device UDIDs. So, our app will install on devices only which UDIDs are added to provisional profile at development stage. We generally added only customer device. So only customer can install the app. The build will not install any other device.
Is there any feature like above in Android?
NOTE: I knew we have feature in Google Play. But, I need this feature while development.
You can filter which users (not devices) can install your app.
In order to do that, use Google Play Developer Console to publish beta application APK - it can be installed only once user joins specific Google+ community or Google group.
So you have to create such a group or community and make it private - this will allow you to filter out which users can join.
After those users join, you will send them test URL and app will be installed on their devices.
Have a look at this Google Play Help article for more details.
The Play Store's method of doing this is via the new beta-testing feature. You add your testers to a Google+ community, and they get access to your application via the Play Store.
If you don't want to use the Play Store, you can implement a restriction within the app itself to accomplish this. The Identifying App Installations Android Blog post has some great information on how to uniquely identify devices. You can use one of these methods to check the device's identifier against a list of "approved" devices in your Activity's onStart(), and simply call finish() if the user is not "approved."
Would an app that requires users to purchase a non-digital product/service to get a login to the app be allowed on the Appstore (iPhone and Android)? If not what would be the correct method for distribution of private app?
There are plenty of apps in the app store that require something external. Nest app, for example, is probably pretty useless without a Nest thermostat. I think the app should just need to behave nicely if you don't have the external thing, the ticket in your case.
At least for Android (Google Play) there should be no problem if you don't force your users in app to purchase something outside of Google Wallet (e.g. in app purchases with PayPal etc., but I guess for buying tickets it's okay - if it is not done inside the app).
Here are their terms for more details: Google Play Terms
An other way would be more open markets like Bazaar (Android) or host it on your own server.
For private apps you can distribute your app under an Enterprise developer account. see here. but you have to pay more ($299/year)