Android multi-app kiosk apps not installing or crashingSolved

Hello @pepijn ,

For Android Enterprise Device Owner devices, adding an app to the kiosk allowlist only permits the app to be used inside the kiosk. It does not automatically install the app.

To silently install apps and make them available in a multi-app kiosk, configure both parts of the policy:

1. Add the apps to the app inventory or Managed Google Play.
2. Add the same apps under the Required Apps section of the policy so they are installed automatically.
3. Add those apps to the multi-app kiosk allowlist so they are visible and usable inside the kiosk.
4. Associate the policy with the device or device group.
5. Ensure the device is online and checking in with the portal.

If the device was offline for a while, actions such as app installation will not complete until the device checks in again.

Regards,
Simon Scott
Hexnode UEM

That explains part of it. We had only added the apps to the kiosk allowlist and not to Required Apps. After adding them to both places, the apps started installing.

But on our Redmi test device, after some time the phone showed “Phone is starting…” and did not load properly. Disenrolling the device fixed it temporarily. After re-enrolling, it worked for 10–15 minutes and then the issue returned after updates/policies synced.

If the device works briefly after re-enrollment and then fails once the policy syncs, isolate the kiosk restrictions first.

Recommended test:

1. Clone the current kiosk policy.
2. Remove the app allowlist configuration from the cloned policy, while keeping only kiosk restrictions.
3. Remove the old policy from the test device.
4. Apply the cloned policy and monitor the device.

This helps confirm whether a blocked app or background package is causing a system component, launcher, or app dependency to be restricted.

For Redmi/Xiaomi devices specifically, some behaviors can also be manufacturer-specific. These devices may aggressively restrict background processes or secure permissions, which can affect kiosk persistence, launcher behavior, and app switching after reboot. If possible, test the same policy on a Samsung Knox-supported device or another enterprise-focused Android model for comparison.

We saw something similar with contacts in kiosk. The app opened, but saving a contact failed with an access denied type behavior. What could be the reason?

For the contact-saving issue or any app that flashes “Access denied,” closes unexpectedly, or fails inside kiosk, check the blocked packages and add the required dependency as a background app.

Steps:

1. Go to Manage > Devices and open the affected device.
2. Run the Scan device action. 
3. After the scan completes, open the device’s Applications section.
4. Check Blocked packages, especially entries logged around the time the access issue occurred.
5. Copy the relevant package identifier.
6. If the package is not already listed as an app, add it from Apps > +Add app > With Bundle ID.
7. Go to the kiosk policy and navigate to Kiosk Lockdown > Android Kiosk Lockdown > Background Apps.
8. Add the required package there.
9. Save and re-associate the policy.

This allows required background components to run while keeping the user-facing kiosk restricted.

How to deal with apps getting stuck or not closing inside kiosk? One app loaded but we could not exit it, and after restarting the phone the kiosk seemed to drop off.

Test the app outside kiosk mode to separate app behavior from kiosk behavior.

You can temporarily disable kiosk from the device actions, test the app natively, and then re-enable kiosk. If the app still crashes, freezes, or cannot close outside kiosk, the issue is likely app-specific or device-specific rather than caused by the kiosk policy.

For Redmi/Xiaomi devices, also note the following known constraints:

• The native launcher may behave unpredictably with managed profiles or third-party management locks.
• Recent Apps and Home button behavior may be affected by the manufacturer launcher.
• Some devices may drop permissions needed for kiosk activation after reboot.
• Background process restrictions may stop kiosk-related services or app dependencies.

Where required, manufacturer-specific workarounds such as granting missing permissions through ADB may be needed. For production deployments that require strong kiosk persistence, silent app management, and stable device-level controls, Samsung Knox-supported devices running Android 11 or later are generally recommended.