How does designing custom android DPC app relate to Android management API?

Question

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

1. Factory reset the android device
2. Reach the screen where user needs to enter their credentials
3. Instead of real credentials I enter afw#setup
4. Device enters into work profile mode and android device policy is being installed
5. I create an enrollment token in the management API (the steps for that are described in the quick start guide
6. I generate a QR code and scan it using the factory reset device as soon as I'm prompted
7. 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.

Answer 1

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.