Android Enterprise is an inevitability. The differences in concepts transcend MobiControl and apply to all EMMs managing Android. I suggest you research and learn about the fundamental concepts of Android Enterprise first before you try to understand SOTI's implementation of them. SOTI's implementation is admittedly confusing at times but it is even more confusing if you don't understand the core principals of Android Enterprise and why that inevitable transition is underway. 

A great place to start is this write up that put together on a recent post:

https://discussions.soti.net/thread/android-enterprise-device-1/

So many diverse questions in one post.  

If you have legacy devices that does not support AE platform, or such devices have been deployed with Android+ device agent and cannot afford device-recall and/or factory-reset and re-enrollment, or your devices are using the critical features only available on Android+ platform, then stick to the Android+ platform using OEM specific device-agents.

If your device firmware supports Android Enterprise and you want to take advantage of the ever-increasing new  enterprise-grade features introduced by Google, your best bet is to choose the AE platform.

The reason for still using the term "Android+" on MobiControl web-console is likely to be due to historical reason in the course of evolution of successive MobiControl versions over the years.   Before AE was introduced by Google,  any device that did not have OEM-specific MobiControl device agent for enhanced (so-called Android+) features could use the generic-Android device agent to support some basic MDM functionalities.  With the introduction of AE platform by Google, all compliant devices can use the generic AE device agent to support the minimum AE features, which are basically more powerful than many legacy OEM-specific Android+ device agent.  So, I believe Soti would like to use the legacy term "Android +" to refer to this improved and unified Android platform.  However, OEM-specific AE enhanced features are only available for devices with corresponding AE plug-in, which can be quite odd to be referred as the "Plus" features of this "Android Plus" platform of AE devices.  Anyway, it's just a name.  No big deal as long as there is no confusion in any communications or documentations.  

Thanks Raymond.

If you have legacy devices that does not support AE platform, or such devices have been deployed with Android+ device agent and cannot afford device-recall and/or factory-reset and re-enrollment, or your devices are using the critical features only available on Android+ platform, then stick to the Android+ platform using OEM specific device-agents.

devices that does not support AE platform generally means before Android 5.0  right ? I understand even if some devices are 5.0+ , they may not support AE platform. But to know if a device supports AE or not, we have to check with the manufacturer/reseller or in websites like https://www.android.com/enterprise/device-catalog ? 
In any case, are there any devices support AE but when enrolled as AE doesn't have some functioanlities available in AP ?. 

If your device firmware supports Android Enterprise and you want to take advantage of the ever-increasing new  enterprise-grade features introduced by Google, your best bet is to choose the AE platform.

 To choose AE platform , either we have to use afw# in the start up (AEDO) Or we should use the agent from playstore (BYOD) , right ?. 

  With the introduction of AE platform by Google, all compliant devices can use the generic AE device agent to support the minimum AE features, which are basically more powerful than many legacy OEM-specific Android+ device agent.  

Generic AE agent you refer to is the one that we get from playstore only or the one we get by using afw# also ?. both these agents are same ?.

OEM-specific AE enhanced features are only available for devices with corresponding AE plug-in.

You are reffering to the .pcg plug-in mentioned here , right ? https://soti.net/mc/help/v15.2/en/console/devices/managing/enrollment/androidplus/enterprise/install_plugin.html

There is another plug-in Android OEM Specific Plug-in available in SOTI website. What is the use of that plug-in ?

AE (previously called Android for Work-AFW) was introduced with Android L but did not become mandatory for OEMs until Android M and higher. Therefore in my opinion is safer to ignore the fact that AE capabilities might exist in L and rather assume that you need Android M or higher. 

The next thing to evaluate are the specific features that you need. Just because Android M supports Android Enterprise that really just means it supports the early management APIs that were exposed in that generation. Newer versions of Android support more Android Enterprise capabilities and so you will find you may be able to accomplish different things with an Android M device under AE versus an Android P or higher device for instance. For this reason, we were holding on to Android+ (DA) for as long as possible in our dedicated device deployments and only made the switch to AEDO for Zebra devices when prematurely forced there in Android O. 

I would recommend if your device is running Android N or higher you should likely be using AE moving forward. 

AE has numerous enrollment methods like NFC, QR, and ZTE that are spelled out in the Google documentation as well as in the SOTI documentation. afw#mobicontrol is what is referred to as the DPC identifier method and is arguably the worst option available in my opinion given the amount of manual steps required and the fact that you can't control the DPC extras that define such things as whether system apps will remain enabled or not post-enrollment.

Manufacturers like Zebra and Honeywell also offer OEM specific AEDO enrollment methods through StageNow and Enterprise Provisioner. These are my preferred and recommended methods if you have these device types given that you can get a device fully provisioned in 1-2 barcode scans directly out of the box. This might not apply to you if you have a different mix of devices however.

Downloading the agent directly from the Play Store is the exact same agent that the afw#mobicontrol method will download on the device. However, the method used for downloading and installing the agent will dictate the enrollment type that you end up with. Downloading directly from the Play Store manually will result in a Work Profile (BYOD) management style whereas afw#mobicontrol (or the other DO enrollment methods that are more preferable) will enroll the device as Work Managed. 

The Android Enterprise Plugins are available for download at the following link. Newer MobiControl environments also include a plugin delivery service that can automatically install the plugin in some cases, although it has been a little inconsistent. 

https://docs.soti.net/mobicontrolagentdownloads

Hello Vikas,

It is very important that you know that in the past, around 4-5 years ago, AE was being born. At this time, we had to work with the manufacturers' legacy APIs, creating several operational problems I want to expose some points here.

1. Profile that applies only to Samsung devices in a time out of AE. This way you had a Samsung profile and an LG profile created on the console to do the similar in different ways and managing that over time becomes disastrous.

2. Constant updating of apps in official stores, apps like Whats App, Banks, Sales, Social Networks demand a lot of updating. This scenario in Android Legacy forces you to always download and upload new apps for MC in your store or for a new installation or send by package or any other method. The .xpak model was also inserted recently in the market it is just an "online installer" to work with tthis kind of applications you cannot send the installation to the device via MC and you ONLY download and install xapk direct from PlayStore on the device

3. Granular control of device features. On Samsung ELM device you can send a profile to set GPS is on or off, on any Android model that allows AE you have the ability to define the type of data capture in gps for example set for High or Battery only, this is just an example, but AE brought granularity to Android settings. Allowing a device to appear less blocked to the end-user as the kiosk mode does. The AE brings security and stability to the device and operations across the world

Our team manages more than 60,000 devices on various EMM / MDM platforms and we no longer have operations running on Android Legacy and all new ones come out with AE enabled and the devices provisioned in ZT and KME when it possible. My suggestion is that you leave the legacy scenario as soon as possible, it should be eliminated in the coming years.

My suggestion is also always to test everything possible in both scenarios looking for the experience of the end-user of the device.