We also discorvered this in our fleet of devices. Some devices have the latest agent versions installed, although we are not updating them ourselves.

I think this is because during enrollment the devices have a connection to Google services. During this process some of the devices are able to upgrade their MC agents through Google Play Store.

We are using a profile "Managed Google Play" and set it to "Never update", but it seems that in the short time slot before the profile is applied, some devices are able to upgrade.   

Hi,

when you enroll the Devices with an QR Code what was created with the Honeywell Enterprise Provisioner.

You are able to say Download the MobiControl APK Version x you want from your own Server in your Newtwork over FTP or SFTP and install it what incluedes the Enrollment to SOTI.

The Device ist then full Wok Managed and when you have set up a Google Account in MobiContol you can say in the "Application Rule" what apps are possible to update.

Is the MobiControl not from your side Approved it will not be updated or the User ist not able to update the Version.

I am not aware that it updated them Selfe....

The SOTI agent versioning is kind of a tricky variable to nail down. This is due to the fact that the agent can actually be upgraded through a couple of different mechanisms. There are technically 3-4 different options for upgrading the agent but at a high level both the SOTI server AND the Google Play server can perform the agent upgrade. The SOTI server can be used to explicitly upgrade the agent to a new version at a scheduled time whereas the Play based install is more difficult to control and is actually something that can be ongoing in the background.

Google Play will detect that the SOTI agent is installed on the devices and will compare that with whatever version it has hosted in the Play Store. If there is a mismatch then it will mark the device as eligible for an upgrade and will perform that automatically once a set of criteria are hit. The device waits for all of these conditions to be true before the app is upgraded automatically

Wi-Fi network and charging conditions are likely to be met on devices quite frequently, along with even the device being idle. However, the last criteria of the app in question not running in the foreground is less likely to occur given the nature of the SOTI agent. The SOTI agent is what powers the lockdown screen on the devices and therefore while the devices are in the charger meeting the other three criteria they are probably failing the last criteria since the lockdown screen is likely to be shown at that point. While the device is in an end users' hands and in use then it is then failing the charging and idle state criteria. This also coupled with the fact that Google Play is maybe only checking for this once every 24 hours means that the window of opportunity for an update to process automatically is actually quite small. 

The end result is result of the automatic updates that are happening infrequently in the background is agent fragmentation:

You can simply wait for this to passively upgrade over time, or you can try to force the upgrade to happen. If you want to upgrade an individual device you can actually launch the Play Store and see that MobiControl is listed as having an available update that you can manually execute:

With these factors in mind, these are the primary options for upgrading your SOTI agent.

• Wait for the agent to be upgraded automatically in the background over time by Google Play
• Manually initiate the upgrade in the Google Play on the devices that you want upgraded
• Use a File Sync Rule to deliver and install a new Agent version in a controlled manner
• Agent Upgrade Service built into SOTI directly.

Hi Marcus,

Yes i use the SOTI wifi wizard from the Enterprise Provisioner to selectively target a specific agent version on enrolment.  This seems to work fine and the devices always are provisioned with the correct version.

The issue then rears its head once the devices have been in production for a time and there's no plausable explanation for their upgrade.

To Matt's points, these are locked down using a kiosk and the users never have access to google play to manually update.  As you mentioned, the kiosk and agent are never not going to be running, so not sure why google would then say it's ok to update in the background as all conditions are not met.

I'd prefer to use the manual agent upgrade options in the console that should deploy the authorised version from the server, it's just a matter of trying to stop these random devices (and by far the minority in the fleet) from updating automatically and finding what's causing them to do so.

It is Google Play that is updating them in the background. That part is not a mystery. The mystery is figuring out how to prevent it from happening.