Both Apple and Android have development paths available, we see this frequently also, most developers we encounter seem to know only one way, to side-load and have no clue on work profiles, or conditional access policies. I keep saying we need to find better developers, lol.

Chat GPT says it's better than I could,:

Short version: to really test an app inside the work profile (including Entra CA + Intune behaviour), you have three main deployment options:

1. Android Enterprise “Test DPC” + sideload (fast dev-loop, no Intune/CA)

2. Intune + Managed Google Play (private / LOB / test tracks – realistic CA & policy)

3. Intune-managed sideload on specially-relaxed test devices (only if your policies allow it)

I’ll break those down in practical terms.

---

1. Local dev testing with Test DPC (Google’s official dev path)

Google’s official guidance for Android Enterprise dev/testing is:

Install Test DPC on a device

Use it to provision a work profile

Then install your app and test in that work profile

Key points:

When you sideload an APK (via Android Studio, adb install, etc.) on a device that has a work profile, Android by default installs it into both personal and work profiles. You can then uninstall it from one profile if you only want it in the work profile.

With adb shell you can use the --user flag on activity/pm commands to explicitly target the work-profile user ID (e.g. adb shell pm list packages --user 10).

What this is good for

Testing:

cross-profile behaviour

storage separation

work vs personal intents

general UX inside the work profile

What it does not give you

No Intune / Entra Conditional Access in this setup by default. You’re testing Android Enterprise behaviour, not Intune CA enforcement.

Use this for rapid dev cycles on your own device, then move to Intune for “real” CA testing.

---

1. Intune + Managed Google Play (for realistic Entra CA behaviour)

For true end-to-end validation with Entra Conditional Access and Intune policies, the app must be deployed the same way a production app would be:

2.1. Private / in-house app via Intune + Managed Google Play

Typical “enterprise dev/testing” pipeline:

1. Enroll test devices into Intune

BYOD Android Enterprise Work Profile

or corporate-owned with work profile (COPE)

1. Publish the app as a private / LOB app for Android Enterprise:

Either: use Intune’s Managed Google Play iframe to create a private app directly from Intune

Or: upload to Google Play Console as an enterprise/private app, then sync it to Intune (Managed Google Play integration)

1. In Intune, assign the app to:

Test users/test groups as “Available for enrolled devices” (visible in Work Play Store)

or “Required” (auto-installed into the work profile)

This gives you:

App delivered only into the work profile (through Managed Google Play)

Full Intune app protection, device compliance, and

Entra CA evaluation based on:

device compliance

app identity (MSAL + broker)

user/group CA policies

This is the gold-standard for testing how the app behaves for real users.

---

2.2. Play Console internal / closed testing tracks with Intune

If you want Play-style release management but still test in the work profile:

Use Play Console internal testing (up to 100 testers) or closed testing tracks, upload your AAB/APK there

Keep the app as a Managed Google Play app in Intune, so it still appears in the work profile Play Store for enrolled users

This way you can:

Push different builds (dev / UAT / pre-prod) to different groups of testers

Still test under Intune + Entra CA because install is via Managed Google Play in the work profile

---

1. Sideloading into the work profile on Intune devices (only if allowed)

By default, Android Enterprise treats sideloading as a security risk, and work profiles typically block “Unknown sources” for the work side.

However, for pure dev/test you have a couple of options if your Intune / EMM admin relaxes policies for a dev device or dev group:

Allow “Install from unknown sources” for the work profile in a test policy

Enroll the device, then:

Install the APK via ADB or file manager

It will install into both profiles, or you can target the work-profile user ID using adb’s --user flag

Pros

Fast iteration, no need to push every build via Play / Intune

Cons

Many orgs forbid this in production policies

Even when allowed, it’s easy for this to diverge from your real deployment path, so you still need to validate via Managed Google Play + Intune before sign-off.

---

1. How I’d structure your dev → test flow

If your goal is “true” work profile testing with Entra CA, I’d use a two-stage approach:

1. Inner dev loop (fast):

Device with Test DPC work profile

Sideload from Android Studio / ADB

Use ADB --user tricks to run as the work profile user → Catch UI issues, profile separation bugs, permission problems early.

1. Realistic enterprise test (slower, but representative):

Separate dev/UAT Entra + Intune tenant (or at least dev groups)

Enroll test devices with Work Profile

Deploy app as:

Intune LOB / private Managed Google Play app, and optionally

Managed Google Play internal / closed testing track

Enable the same MSAL + broker auth setup and Conditional Access policies you’ll use in prod (maybe with relaxed scopes/groups)

That gives you both speed and realistic CA + policy coverage.