My question might seem really stupid, to those who have worked on android Airwatch implementation. But their documentation is not very well written, and I have a few doubts.
So I have setup my user, and added my device using airwatch console.
I have added the App restrictions code in my existing android application.
I have also added the key, values to be pushed to application, via Airwatch Agent app.
But I do not receive these key, values, which I should when I execute the following code :
Bundle appRestrictions = myRestrictionsMgr.getApplicationRestrictions();
The appRestrictions bundle is empty.
I read some where in the docs, that the AppConfig requires Android 5.0+ with Android for Work Device.
Does this mean I have to enable android for work capability on my android device? Is this required even for development purpose?
I tried in vain doing so using this link : https://support.google.com/a/answer/6178111?hl=en. Can some one please share a doc, to enable android for work capability on my android device, if this is required.
You will indeed need Android for Work in order to use Airwatch to configure your application.
You should ensure you are using a device that supports AfW. All devices with Android 6.0+ support work profiles, as well as many devices with Android 5.0+. Some recommended devices can be found here
Once you have done so, you should create a new Profile in the Airwatch console that ensure that they will create a work profile on your device. Go to Devices >> Profiles >> List View and Click on "Add" >> "Add Profile" and choose "Android" >> "Android for Work"
This should allow you to create an AfW policy that will apply to any assigned groups. Any apps you push to these devices can be configured using the App Restrictions framework by editing an application, going to the "Deployment" tab and enabling "Send Application Configuration". You should be able to set the key value pairs from there.
All that being said, if you are testing from a development perspective, you are much better off testing with TestDPC, an open source testing tool Google makes available in Google Play (just search for "TestDPC") and on Github
There is a user guide on github, but it is very easy to use for creating work profiles, setting app configurations using app restrictions and more.
I would use Airwatch once you are ready to do production testing, but TestDPC is a much better tool while you are still developing.
On Android the key-value pairs must be validated by Google Play.
There are 2 ways to achieve that:
Publish your app to the Google play store (see Wandera app, for example)
Publish your app in the company private store. To do this you'll need to configure your Android for Work account
On iOS is simpler, just specify the key-value pairs at assignment time.
For AirWatch, your key-value pair information belongs to CustomSettings, so you should use the APi to retrieve CustomSettings, like below:
final boolean isEnrolled = awSDKManager.isEnrolled();
if (isEnrolled) {
final String settings = awSDKManager.getCustomSettings();
}
Related
I need some help with my app that I build for Android TV.
I already make a COSU app for Android TV, but the problem is I need to use adb shell to make my app as device owner. Is there a way to make my app as device owner programmatically? Because I will install my app in +100 STB devices. I tried a method from SO answer, but it's not working.
I still can't figure it out how to update my app later if there is a new version of my app, because like it said in here, I can't use Android Management API on Android TV and also I think I can't use Google Play to update a COSU app. Is there a better approach to update my app?
Need help.
Thank you.
Since your app got device admin permissions, your app can update itself silently in background using PackageInstaller API. All you have to do is to just download the new apk when available and forward it to PackageInstaller which can update and install your new apk.
Here's a sample if you wanna look how to implement it: author's link is dead (after edit link - I think they are similar).
You can't make your app device owner programmatically unless the device is rooted. Here's a list of options by Google to make device owner remotely.
Provisioning google dev docs.
I'm new to android enterprise development world, and I have some misconception of how different pieces in the android enterprise ecosystem relate to one another. Let me explain.
The solution that I'm trying to achieve is being able to lock the device into kiosk mode both remotely, and also based on some business logic do it even when the user is offline. I started investigating EMM and particularly Android Management API to solve the problem. I was able to lock the device remotely into kiosk mode using the API. The steps that I take is following
Factory reset the android device
Reach the screen where user needs to enter their credentials
Instead of real credentials I enter afw#setup
Device enters into work profile mode and android device policy is being installed
I create an enrollment token in the management API (the steps for that are described in the quick start guide
I generate a QR code and scan it using the factory reset device as soon as I'm prompted
The device will be linked to the enterprise, and I'm successfully being able to control it and put the device into kiosk mode by creating special kiosk mode policy and patching the device to comply to that policy using a combination of patch policy (to create a policy) and patch device APIs.
The next step was finding out a way to lock the device into kiosk mode even when user is offline. I assume that it's going to happen by creating an android enterprise custom DPC (device policy controller) application. I assumed that by reading the following documentation, where one of the 3 ways of provisioning "single purpose" devices is creating a custom DPC application. Here's another quote from different url
As an EMM, you develop a DPC app that can be used by your customers in conjunction with your EMM console and server. Your customer deploys the DPC to the user devices that they manage. The DPC acts as the bridge between your EMM console (and server) and the device. An admin uses the EMM console to perform a range of tasks, including configuring device settings and apps.
And here's where all of my confusions arise.
First question that naturally arises - was the author of the previous quote referring to EMM management API when talking about EMM console and server?
Further, there are more questions that I couldn't find an answer to
In the guide for creating a custom DPC there are no mentions about what role EMM API will play in custom DPC, and consequently there's no place I could find that describes how exactly the custom DPC is a bridge between the EMM console (presumably EMM API) and the device?
Then, let's assume I've developed a custom DPC application and uploaded it to google play alpha channel. The documentation states that during the setup process instead of entering afw#setup I should enter afw#DPC_NAME, and I have no idea how to generate that name? Is it the bundle ID of the DPC app? Or perhaps it's being set somewhere in google settings? For instance, google has developed the TestDPC application to test enterprise solutions, and I was able to go through the steps I described above and enter afw#testdpc and successfully scanned the QR code in the git readme file and I saw that TestDPC was installed and device was launched into work profile mode. So, I assume somehow I need to register my own "testdpc" and enter afw#my_dpc instead.
Basically I have different pieces working stand alone and I want to form a broader picture in my mind to understand how to stitch those pieces together.
Thanks for your answers
UPDATE 1:
Today I found a way of turning custom DPC into device owner without going through NFC or other provisioning process. This is particularly useful for development purposes. Follow this link for instructions.This is both huge time saver, and also, in my case, we still are waiting for google's approval, but finally we can start testing some stuff without the need of custom provisioning process.
There are two distinct ways of managing Android devices:
The new way: the Android Management API. It is the way recommended by Google and it's significantly simpler than the old way, you don't need to call other APIs or to create a custom DPC. If your use case is not addressed by this API you can send feedback to Google so they can add the missing features.
The old way (no longer available for new deployments as of 2019-12-20): using custom DPC. For that you need to:
create a custom DPC,
register your custom DPC with Google by joining the EMM Community (this is how you get the afw#DPC_NAME),
use the Google Play EMM API to install apps.
In the documentation you - the developer using these APIs - are referred as "the EMM". "EMM server" refers to the server that you own and that calls these API, and "EMM console" refers to the UI console that you expose to your IT admins, if any.
https://developer.android.com/work/dpc/build-dpc
Caution: Android Enterprise is no longer accepting new registrations
for custom device policy controllers (DPCs). Learn more.
Hi #Fred,
I found this above information from the mentioned path.
I have some questions regarding the above conversation.
If we use Android management API to develop EMM, we don't need to implement Custom DPC app?
Whether we can register a account in EMM community with Custom DPC app?
Is it possible to use a custom DPC app with Android management API?
My question is specifically about one line in Android documentation here. https://developers.google.com/android/work/prov-devices#set_up_device_owner_mode_google_account . Particularly item #2 where it says
The DPC is automatically downloaded to the device and launched.
How?
Specifically, what is the trigger that launches the DPC after download while still in the context of the startup wizard? I'm asking because it isn't working for me.
I've got Corporate-Owned Single Use (COSU) application, but I'm getting tripped up on deployment -- specifically the part where the DPC app sets itself as the device-owner. So far, I've loaded the app in Google Play Store as a private application. G-Suite exists in the same domain and Google is registered as the EMM for the account. The COSU app is whitelisted and installs as part of the setup wizard... but it doesn't launch.
To the best of my understanding, it has to launch within the context of factory-reset so that I can reset the device owner to the downloaded app.
Is there a specific Activity or BroadcastIntent I should be looking for? I'm new to Android, so I've been pouring through the TestDPC code, Android docs, and SO posts, but this deployment thing is a pain.
As a secondary query. How would you debug this situation? Its all factory-reset and install by wire, I don't have the opportunity to turn on developer mode and watch logs through Android Studio as it happens. And pushing new builds to Google Play and resetting hardware to download and install has a very long cycle time.
Thanks in Advance
For your DPC to be downloaded and launched after an account is added you need to register as your own EMM along with your DPC, and enroll your G-Suite domain with this EMM.
It might be simpler for you to instead use Google's new Android Management API which doesn't require implementing a DPC or registering as an EMM.
I'm trying to implement an MDM client app for Android, known in the Android For Work world as a Device Policy Controller or DPC. Google's documentation for building a DPC is here.
The documented process begins with downloading the DPC Support Library. Unfortunately, the download link they provide (to the "EMM Community's Technical Integration" section) doesn't work: you're prompted to log in with a Google account, but after doing so I see this:
We’re sorry...
...but it looks like you don’t have access to this place or content. If you think you should have access to this space, try logging out and back in again using your account menu accessible by clicking your avatar in the top right corner of this page. If this issue persists, please notify your Support Representative and we will troubleshoot further.
Others have had the same problem: there's an issue ticket raised here which is only 2 months old, has no answer but for some reason has been marked Assumed Answered and then ignored.
The steps documented here make it very clear that the DPC Support Library is a required part of the process, and don't describe any alternatives to using it.
So, how do I get hold of the DPC Support Library? Can it be obtained anywhere else? Or failing that, how do I find out what it does so I can reproduce those steps manually in my own code?
Some steps I've already tried:
I have successfully registered for the EMM Community and have access to the EMM API. (i.e. I get a valid response now from Enterprises.generateSignupUrl, and no longer the dreaded "The caller is not registered as an MDM".) That in itself was a long and frustratingly opaque process.
I have built and run the googlesamples/android-testdpc app and looked through the source code. Unfortunately this is a client-only demo: it doesn't communicate with an EMM server and doesn't use the DPC Support Library. Specifically, it doesn't obtain an authorisation token in order to provision a work profile on the device, as documented here.
I have played with the public EMM demo system and its DPC app. That seems to be doing things properly, but as it's closed-source I can't look at the code for either client or server.
Well I now have access, so in that sense I have an answer, but I don't know how useful it'll be to others.
A Google representative replied to my forum post here and granted my organisation access to the EMM Community. Once that was enabled, the steps were as follows:
Create a new Google account using my work e-mail address
Sign into the Cloud Connect portal with that account
Click on EMM Community
Scroll down to the Featured Technical Guidance section and look for the DPC Support Library download link
An alternative to build your own Device Policy Controller app is to use the Android Management API and therefore not have to use the DPC Support Library. This API doesn't have all the features you can get by building your own Device Policy Controller app, but is significantly simpler to implement.
I am new to Android for work features.
I have written a sample app to test the restriction features provided to a profile owner. My sample app creates a managed work profile and sets itself as the profile owner.
I tried to apply some restriction policies after that, e.g., DevicePolicyManager.addUserRestriction(componentName, UserManager.DISALLOW_UNINSTALL_APPS);
It works and I am unable to uninstall any app from the managed profile. But when I try to apply: DevicePolicyManager.addUserRestriction(componentName, UserManager.DISALLOW_INSTALL_UNKNOWN_SOURCES);,
it seems to be not working.
I couldn't find the default settings app enabled in the profile.
But when I log the apps installed in the managed profile, I can see two setting packages (com.android.settings and com.android.providers.settings) in the list.
What my understanding from the above API is after applying the restriction, Setting->security->Unknown Source switch should be disabled. But I couldn't find any Settings app in the managed profile to verify.
Also, after applying the restriction, I am able to install any apk from adb in the managed profile along with the primary user.
Please let me know if i am missing something.