(COPE) Hide app in work profile

Hello, I have a small case I'd like to submit to the community for help please.

A customer use Mobile Iron, and use Zero Touch to enroll our Android 14 products. In their DPC extras, they enabled the system apps and need to keep that way:

"android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED":true,

"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE":{

"workProfileEnabled": true,

"quickStart":"true"

}

Now after the device is enrolled, the Work profile is filled with bunch of apps including unwanted ones like Netflix, Adobe, YT kids, ...

From Mobile Iron, they want to hide/disable some apps, using "setApplicationHidden" but it doesn't work. At OEM side, we tested this API with the Test DPC and it works properly.

My thinking was that as we are in COPE, and the apps that the customer wants to remove are from the Personal space, then this is not working as the MDM cannot interact with Personal space content. Does this make sense? Are there a way to hide the unwanted apps from the Work profile, despite having "leave all system apps" enabled from the ZT DPC extras?

Anyone has any suggestions please?

Thanks!

Alex_Muc
Level 2.3: Gingerbread
2 months ago
I don't know the exact configuration in Ivanti (/Mobileiron) for blacklisting apps.
For Android Enterprise / Work Profile you can set up an app control and block specific app IDs.
If apps are disallowed via App Control, they can no longer be used in the Work Profile.

This might help:
https://help.ivanti.com/mi/help/en_us/cld/admin/ivanti/91/all/en-us/Allowed_apps.htm
- Yunchuan
  Level 2.0: Eclair
  2 months ago
  Thanks for the suggestion, but this policy will trigger only after an user will launch a listed app, but not hide or disable the app directly from the work profile
Kumaresh90
Level 2.0: Eclair
2 months ago
YunchuanYou would need to use App control configuration to block personal apps on COPE devices:
https://help.ivanti.com/mi/help/en_us/cld/admin/ivanti/91/all/en-us/App_Control_for_Devices.htm
- Yunchuan
  Level 2.0: Eclair
  2 months ago
  Thanks for the suggestion, but this policy is to disallow app installation but cannot interact with already installed app on the device
  - Moombas
    Level 4.1: Jelly Bean
    2 months ago
    I want to highlight 2 things here:
    You set "android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED":true how about setting this to false? Normally then most of such apps should disappear during enrollment.
    We have a notification in our web console when i look into it, telling that AMAPI is not supported for personal profile for one of the policys (application run control) and we have to choose another one (personal play policy). So there seem to be 2 different API's to work with in order to get this done. I don't have COPE devices to test with.
    I also don't know what kind of API's are behind them but there seem to be something.
Rakib
Level 2.2: Froyo
2 months ago
Another way to solve it could be to remove those apps as system apps and select uninstall. Here is how we do it in Intune.
- Moombas
  Level 4.1: Jelly Bean
  2 months ago
  But that would still let them being allowed to install them afterwards manually through the private profile and i guess that's something they don't want to.
Alex_Muc
Level 2.3: Gingerbread
2 months ago
Yunchuan
Can you say what the customer's purpose is for “LEAVE_ALL_SYSTEM_APPS_ENABLED:true”?
Is there a included non-system app that would otherwise not be available? Or is a certain system app simply no longer available in the Work Profile?

Has the customer tested the policies with devices from another OEM? Can apps be deactivated correctly in the Work Profile?

I don't know the current status at Ivanti regarding CustomDPC vs. AMAPI. If a CustomDPC is still in use, we actually have a good comparison with WorkspaceONE. However, I cannot reproduce the problems described.
We have the option to blacklist apps. (For Work Managed and in the Work Profile) This uninstalls (non-system) apps. System apps are blocked and hidden. However, you can also explicitly enable system apps if, for example, they have been deactivated via the DPC Extra. For example, we would only need “LEAVE_ALL_SYSTEM_APPS_ENABLED:true” for Work Managed devices if an OEM supplies a non-system app that is not available in the PlayStore.
- Yunchuan
  Level 2.0: Eclair
  2 months ago
  Thanks for the suggestions.
  
  They have indeed tested on 2 of our products, the policies work on our old model running Android 12 but don't work on our newer model on Android 14
  
  Ivanti uses this API: https://developer.android.com/reference/android/app/admin/DevicePolicyManager#setApplicationHidden(android.content.ComponentName,%20java.lang.String,%20boolean)
  - Alex_Muc
    Level 2.3: Gingerbread
    2 months ago
    Yunchuan
    Hm, that could be a bug in the newer model. It doesn't seem to be due to the configuration and we don't have any problems with Android 14.
    
    Have you ever requested a bug report / verbose logcat logs from the customer? Ideally, you might see errors there. The policy controller triggers the action and the system gradually works through the necessary steps. Maybe an error occurs during a single action, as a result of which the app remains visible in the launcher. But that's just a guess for now.
    
    For example, these are two of many pieces of information when Google Meet is deactivated in the Work Profile (=userId 10):
    02-28 12:18:37.159 1167 31382 I PackageManager: setApplicationHiddenSettingAsUser, packageName: com.google.android.apps.tachyon, userId: 10, hidden: false, callingUid: 1000, callingPackage: system 02-28 12:18:40.827 1167 1367 I SettingsProvider: onPackageRemoved (userId 10) PackageName = com.google.android.apps.tachyon