Android kiosk devices showing Install screen during Hexnode agent updatesSolved

Hi @haanaa,

Hexnode agent updates on Android can be silent, but the behavior depends on the enrollment method, app privileges, and how the agent update is being delivered.

For silent Hexnode UEM Android app updates, check the following:

1. Go to Admin > General.
2. Enable Automatically Update Hexnode UEM Android App.
3. If available in your portal, also enable the option that automatically grants the required permissions during Hexnode app updates.

When this automatic update option is enabled and the device has the required management privileges, the Hexnode agent update should be installed silently. If the update is handled outside this flow, or if the device lacks the required privileges, Android may display the standard install screen even when the device is in kiosk mode.

For scheduling: Hexnode supports scheduling Android OS updates during inactive hours, but there is no separate native maintenance-window scheduler specifically for automatic Hexnode agent self-updates. If you need strict out-of-hours control, the practical workaround is to disable Automatically Update Hexnode UEM Android App, upload the newer Hexnode app version as an Enterprise app, and deploy it manually during your maintenance window.

For notifications: Hexnode does not currently send a proactive alert immediately before an automatic Hexnode agent update is executed. If your environment requires version-change approval, manual Enterprise app deployment gives you the most control over when the update is pushed.

For minimum network access, no inbound management ports need to be opened for Hexnode MDM communication. The following outbound access should remain available for Android device management, command delivery, and app/agent downloads:

• HTTPS/TCP 443 to your Hexnode portal URL.
• HTTPS/TCP 443 to static.hexnodemdm.com and downloads.hexnode.com.
• HTTPS/TCP 443 to the Amazon S3 endpoints used for your Hexnode region, for app and file management.
• MQTT outbound TCP 1883 and 8883 for real-time command delivery.
• Firebase Cloud Messaging access on TCP 5228, 5229, 5230, and 443 so Android devices can receive push notifications and wake for management actions.
• DNS on TCP/UDP 53 so devices can resolve the required service hostnames.

Under a minimum-endpoints policy, keep the permanent access limited to the services required for portal communication, app/content downloads, MQTT command delivery, FCM push delivery, and DNS resolution.

Regards,
Isabel Lora
Hexnode UEM

That explains what we’re seeing. If we disable the automatic Hexnode app update and push it as an Enterprise app, will the update still be silent on kiosk devices? Or should we expect the install prompt in that case?

Manual deployment can still be silent only if the Android device is managed with the required privileges for silent app installation. In fully managed Android deployments, app installation and updates can usually be handled without user interaction. However, if the device is not provisioned with sufficient management privileges, Android may still show the installer UI.

For signage or kiosk fleets where interruption must be avoided, test the manual Enterprise app update on a small staging group first. If it installs silently there, you can use that method to control the rollout window while avoiding automatic daytime updates.

Regards,
Isabel Lora
Hexnode UEM

We had a similar setup and ended up keeping automatic updates off for production signage tablets. We test the new Hexnode app version on a few spare devices, then push it after hours. It’s a bit more manual, but it gives the network and operations teams a clear change window.

Just to confirm the network side: we don’t need to open inbound ports to the tablets for commands, right? Commands are delivered through outbound communication plus push services?

Correct. Hexnode does not require inbound firewall openings to the managed Android devices for normal MDM command delivery.

The devices initiate outbound communication to the required Hexnode services and use push notification services such as Firebase Cloud Messaging to receive wake-up notifications. Once the device is reachable and notified, it checks in and processes pending commands through the allowed outbound channels.

Regards,
Isabel Lora
Hexnode UEM