Managed Home Screen kiosks: taming dialer packages, notification trays and screen-wake

Managed Home Screen kiosk builds fail in predictable ways: the phone app will not pin because every OEM names its dialer differently, incoming calls vanish along with the notification tray you just locked down, and the settings that govern it all live in three different places. Here is the map.

The problem

You have enrolled Android devices as Android Enterprise dedicated devices in Intune, set Managed Home Screen (MHS) as the kiosk launcher, and now need a shared frontline handset that can actually take a phone call. The symptoms stack up quickly:

• Incoming calls only surface in the system notification tray — the very tray you disabled to stop users escaping the kiosk. Lock the tray down and calls arrive silently or not at all.
• The Phone app will not pin. MHS pins apps by package ID, and there is no standard dialer package on Android. A profile built and tested on a Samsung breaks the moment it lands on a Zebra or a Pixel.
• Screen-wake on an incoming call is trial and error. One model lights up and rings; an apparently identical build on different hardware stays dark.
• The settings are scattered. Kiosk behaviour is split between the device restrictions profile, the MHS app configuration policy, and (increasingly) the newer Device Experience settings — with no obvious owner for any given behaviour.

This is common enough that a long-running Microsoft Tech Community thread — Managed Home Screen Woes — exists specifically to consolidate fixes, in the thread author's words, "from Reddit, Microsoft, and personal blogs". When the canonical documentation for a scenario is a community thread aggregating forum posts, you know the product surface is genuinely awkward.

Why it happens

Several separate design realities collide in this scenario:

MHS is a launcher, not a firmware layer

Managed Home Screen replaces the home screen and constrains app launching. It does not own the telephony stack, the notification shade, or power and display management — those remain the OEM's, and every OEM does them slightly differently. MHS can hide the shade; it cannot re-route where Android chooses to announce an incoming call.

Android has no standard dialer package

The system dialer is whichever app holds the android.app.role.DIALER role, and OEMs ship their own: com.samsung.android.dialer on Samsung, com.google.android.dialer on Pixels and most Google-dialer OEMs, plain com.android.dialer on AOSP-based rugged devices. Because MHS pins by package ID, a mixed-OEM estate needs per-OEM knowledge that appears nowhere in the Intune UI.

System apps are disabled by default on dedicated devices

On dedicated-device enrolment, Intune disables most preloaded system apps — including the phone app — until you explicitly re-enable them. So even the correct package ID produces nothing until the app is force-enabled as an Android Enterprise system app.

An incoming call is two UI components, not one

Android announces calls via a heads-up notification (which dies with the notification tray you blocked) and displays them via a full-screen in-call activity — which on some builds is a separate package (com.android.incallui; com.samsung.android.incallui on older Samsung firmware). If the in-call package is not allowed in the kiosk, the call screen cannot draw over MHS.

The settings surface is mid-migration

Historically MHS was configured through an app configuration policy full of JSON-backed keys, while kiosk mode itself lived in the device restrictions profile. Microsoft has been consolidating MHS settings into the Device Experience section of device restrictions, so the same behaviour can currently be expressed in more than one place — and duplicating a setting across surfaces produces version-dependent results. Screen-wake behaviour, meanwhile, is OEM power management and is not directly exposed as an Intune setting at all, which is why it feels like guesswork: it is.

The fix

A repeatable recipe, in the order that avoids re-work:

1. Establish the true dialer package on your exact hardware

Do not trust generic lists (including the one below) as final — verify on the device model and firmware you will actually deploy:

• adb shell pm resolve-activity --brief -a android.intent.action.DIAL — shows which package handles the dial intent.
• adb shell dumpsys role (Android 10+) — search the output for android.app.role.DIALER to see the role holder.

Starting points by OEM:

Also check whether the in-call screen is a separate package on your build (com.android.incallui, or com.samsung.android.incallui on older Samsung firmware). If it is, it needs allowing too.

2. Re-enable the phone app as a system app

In Intune: Apps > Add > Android Enterprise system app, enter the package name from step 1, assign as Required to the dedicated-device group. Skip this and the correct package ID still yields a blank tile, because system apps are disabled by default on dedicated devices.

3. Pin it in the kiosk

Add the dialer package (and the in-call package where separate) to the multi-app kiosk allowed apps / custom app layout in your device restrictions profile. If you instead manage the app list through the MHS app configuration policy, pick one surface and stay on it — do not define the list in both.

4. Decide your notification posture deliberately

If you fully block the status bar and system notifications, call alerts go with them. There is no per-app carve-out in the kiosk profile — it is all-or-nothing per surface, which is exactly why so many builds descend into trial and error. Test the specific combination on your hardware: with the shade locked, does the full-screen in-call activity still fire on an incoming call? On builds where it does not (only a heads-up notification is raised), you will need to permit system notifications for calls to surface, and accept the trade-off or mitigate it elsewhere in the profile.

5. Handle screen-wake with the screensaver, not display sleep

A device that is merely showing the MHS screensaver is still awake and reliably presents an incoming call; a device whose display has fully slept is at the mercy of OEM power management. Prefer enabling MHS screen saver mode with a long display timeout over letting the panel sleep, then test a real incoming call on every OEM and firmware combination you deploy and record the result in your build documentation — this behaviour shifts between firmware versions.

6. Contain the settings sprawl

• Where a setting exists both in the MHS app configuration policy and in Device Experience, treat Device Experience (device restrictions) as the owning surface — that is Microsoft's direction of travel.
• Never set the same key in both places; the interaction is version-dependent.
• Build one profile per archetype — single-app kiosk, multi-app-with-phone, scanner device — rather than one mega-profile with exceptions.
• Export and document the finished profiles (for example via Microsoft Graph) so the next administrator inherits a written configuration, not a Reddit archaeology project.

How Decolla handles it

Honestly: it does not. Decolla provisions Windows devices over your own Intune/Autopilot tenant — it does not configure Android, Managed Home Screen, or dedicated-device profiles, and we will not pretend otherwise. If your problem today is purely the Android kiosk above, the recipe in this article is our best help, and it works without Decolla.

What Decolla does address is the same failure pattern on the Windows side of the estate most Android kiosk admins also run: settings scattered across profiles, per-hardware quirks, and fixes hand-assembled from forum threads. Decolla's Library is a curated catalogue of 260+ items across 21 sections — pre-built, industry-tested policies, scripts and fixes, including recurring helpdesk fixes and built-in hardening — assembled through a wizard into a written, itemised plan. Every item states its delivery method and reversibility class (automatic, reversible, or flagged irreversible) and the plan is approved before anything runs; deployment is then unattended in your tenant, with per-item rollback of Decolla's own changes.

Decolla is pre-launch and waitlist-only at decolla.app.

Sources

• Managed Home Screen Woes — Microsoft Tech Community (Intune)
• Shared Android: phone calls from kiosk mode — r/Intune