I am working on a custom EMM MDM solution. I did a lot of study about it and I came across these two APIs.
Android Management API
Google EMM API
Now I have few questions about these two APIs
I did about these two APIs individually but i don't why i find these
APIs similar in functionality I just want to know the main
difference between of both these APIs or advantage and disadvantage
of both APIs.
While provisioning a device with android management API, In DPC identifier method we write afw#setup when prompted to sign in which downloads Android Device Policy application but other MDMs for example In tiny MDM when user is going to enroll device, he writes afw#tinymdm when prompted to sign in which downloads their own application. Now what i need to do develop my own application and i write a code which downloads my app and user gets enrolled
What is actually NFC? In the documentation they wrote there is an admin device and u need to bump other device with admin device to enroll device. I did same but nothing happens.
How can i share the files and contacts with all enrolled devices in android management API
How can i track the physical location of device in android management API
I eagerly wants the answer of these questions that I found nowhere yet.
Google is no longer accepting new registrations for the Play EMM API. It is mentioned on all EMM related webpages, this is done so that developers can start using the latest Android Management API.
afw#setup is the identifier for Android Management API, it will download the Android Device Policy and continue to setup. afw#name are identifiers of EMMs which were built on Play EMM APIs and have their own DPC - Device Policy Controller and now Google doesn't accept new identifiers.
NFC enrollment is a process to provision a device. Link
Would suggest to perform more research on Android Management API and also understand the options better.
How can i share the files and contacts with all enrolled devices in android managment API
There is currently no way to achieve this using Android Management API. However, you are free to use third-party applications to achieve this.
How can i track the physical location of device in android management API
This has been answered here.
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.
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.
Our app uses PayPal to make payments for a service through our iOS and Android apps. We are preparing for submission and need to switch from sandbox to live. However the Paypal documentation is quite unclear!
Our app is listed under REST API apps (rather than Classic API apps). Is this ok if all we intend to do is take payment via Paypal account and direct/credit card?
The process of registering a REST API app is quite different to registering a CLASSIC API app. If we want to register as a CLASSIC API app then Paypal require legally recognised documents and an apk/ipa for testing. I imagine that will add significant time to our project as it will need to be reviewed manually (which we can't afford the time cost).
So are we safe to continue with the REST API app? We've implemented the latest Paypal mobile sdk's into the apps and have a fairly straightforward scenario (accept non-recurring Paypal and credit card payments).
The main difference is that REST is built around oauth and is designed for environments where you have to have that feature (i.e. some mobile platforms natively support it).
Classic can be run with either soap or name-value pairs(NVP). It contains a much simpler authorization scheme but Classic has been around longer and has a number of calls that REST does not yet support. Some notable exceptions include
MassPay (send money to a PayPal account via API)
Adaptive Payments (split payments between multiple accounts)
Now, you tagged this android. So if you want to publish your app in Google Play or Amazon Appstore, understand that you may not accept some payments within your app via PayPal without violating their TOS. Both Google Play and Appstore require you to use their payment systems for virtual goods. From the Google Play TOS
Developers charging for apps and downloads from Google Play must do so by using Google Play’s payments system. If your app offers virtual goods or currencies to be used within the app, it must use Google Play’s in-app billing service as the method of payment.
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'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?