Skip to main content
MW_dm
MW_dm
New Member
May 26, 2026
Question

Managed Home Screen – opening PDFs via the "android" system app

  • May 26, 2026
  • 2 replies
  • 149 views

Hi Community,

we're running shared Android devices (1,000+) with Microsoft Managed Home Screen (MHS) enrolled via Intune in Dedicated Device mode.

The Problem: Users couldn't open PDFs from within apps – the "Open with…" picker dialog never appeared, so files simply didn't open.

Microsoft's suggested fix: Add the system app with package ID android to the allowed apps list in MHS and include it in the Device Restrictions policy. After deploying this app, the "Open with…" dialog started appearing correctly and PDF opening works as expected.

Before we roll this out to 1,000+ devices, we have two questions:

1. What exactly does enabling the android system app unlock? The package android is essentially the Android framework / core OS package. We're not sure what capabilities or UI surfaces get exposed by whitelisting it in MHS beyond the intent picker. Does it give users access to any system settings, dialogs, or functionality they shouldn't have on a kiosk/dedicated device?

2. Is there a safer or more targeted alternative? Ideally we'd only enable the intent chooser/picker without broadly whitelisting the core OS package. Has anyone solved this differently, for example:

  • Setting a default PDF handler via app configuration (managed config) so no picker is needed at all?
  • Using a specific intent filter or URI handler approach?
  • Any OEM-specific or Intune policy that addresses this more granularly?

We want to be confident before pushing to production at scale. Any insights from admins who have hit this or have deeper knowledge of what the android package exposes in a kiosk context would be hugely appreciated!

Thanks in advance

    2 replies

    Rakib
    Rakib
    Level 3.0: Honeycomb
    May 26, 2026

    What other apps have you enabled, how about just using Edge/Chrome and block and enable what services you need with app config.

      SF4
      SF4
      Level 1.6: Donut
      May 28, 2026

      Jumping in on behalf of my colleague ​@MW_dm who is currently out of office. Thanks for the suggestion, Rakib. 

      The issue isn't which PDF viewer app is being used. We've tested with Edge, Chrome, Adobe Reader, and others. The root cause is that the "Open with…" / "Complete action using" dialog itself is suppressed by MHS before any viewer app is ever invoked, even when there is only one PDF-capable app installed.

      The dialog needs user acknowledgment regardless of how many viewers are available. It's a system-level intent resolution step, not an app-specific one.

      What makes this particularly puzzling is that PDF opening worked correctly until a few months ago. The picker dialog was shown as expected. Something changed (likely a newer MHS version and/or an OS security patch) that now suppresses this dialog entirely.

      The Microsoft-suggested workaround (whitelisting the `android` system package in MHS) does restore the dialog, but as mentioned in the original post, we're cautious about what else that might expose in a kiosk context at 1,000+ device scale.

      Our ideal solution would be to set a **default PDF viewer app via managed config** so the picker is bypassed entirely and users go straight to the viewer – has anyone achieved that in a Dedicated Device / MHS setup?

      Alex_Muc
      Alex_Muc
      Level 3.0: Honeycomb
      May 27, 2026

      Omnissa has implemented this well in its kiosk solution. In the config there, you can allow a specific class within a package. So, technically, it is possible for kiosk apps to allow certain dialogs without having to whitelist all system dialogs.

       

      During my tests with Intune, I didn't find any such configuration options. Perhaps it's possible to use the JSON data to restrict an app to a specific class, but I couldn't find anything specific about this in the Microsoft documentation. The package name should be “android” and the class name should be “com.android.internal.app.ChooserActivity”.

       

      If no one here has configured something like this yet, you should at least ask Microsoft whether the JSON data can be restricted in this way, before whitlisting “android”.

        SF4
        SF4
        Level 1.6: Donut
        May 28, 2026

        Thank you ​@Alex_Muc , that's a really helpful pointer! The class-level allowlisting approach that Omnissa supports sounds like exactly the kind of targeted solution we're looking for. 

        We'll explore two angles based on your suggestion:
        1. Whether the MHS app config JSON supports specifying a class within a package (i.e., `android` / `com.android.internal.app.ChooserActivity`), and if not, we'll probably open a new Microsoft support ticket as you recommended, though our existing ticket hasn't yielded much progress so far.

        2. Whether an OEMConfig setting could achieve the same result as the Omnissa implementation.

        Will report back once we've had a chance to test. Thanks again!

        Terms & ConditionsAccessibility statement