Forum Discussion
How to Handle Delisted Apps in Google EMM During or After Device Provisioning?
Hi everyone,
We’re facing an issue where managed Android devices get stuck, preventing app installations when an app included in a policy is delisted from the Play Store.
For example, we had the package “com.Xplayer” in a device policy, but when calling Products: get, it returned:
“googleapi: Error 404: No product was found for the given ID., notFound.”
However, this app was available earlier, and despite its removal, using the Devices: update API still updates the policy without any error or warning.
Additionally, there’s a possibility that an app is present on the Play Store when it is approved and added to the policy but later gets removed or delisted by Google. This could lead to installation failures and devices getting stuck.
Has anyone encountered this before?
- How can we prevent devices from getting stuck when an app is delisted?
- Does EMM automatically remove such apps from policies, or do we need to handle it manually by checking each package ID?
- Is there any way to get notified when an app is removed from the Play Store?
Without a proactive mechanism, devices remain in a stuck state, making large-scale device management challenging. Any insights or best practices would be greatly appreciated!
Thanks!
Hello,
There is no way to be notified when an app is removed from the PlayStore.
The EMM could regularly check if the apps are still available on the Play Store, for example, but at the end when deploying an app you should always make sure that it's available to the device (it can be on the Play Store, but can also be a system app...) before adding it to the policy.
There is no automated way to do that, the policy is always valid even if the package name is not on the Play Store (like system apps).
Devices should not be stuck, and this should not prevent other apps to be installed on the device.
Thank you for your response jeremy !
I understand that we should verify app availability before adding it to the device policy. However, suppose there are 20 packages in the Google device policy that we want to install on a device during provisioning. Does this mean we need to call the Products: get API 20 times—once for each package—to check if it’s still available before calling the Devices: update API?
This approach seems inefficient, especially at scale. Is there a more optimized way to handle this scenario? Any best practices or alternative recommendations would be greatly appreciated.
Thanks!
It’s not an issue to push a policy with package name that are not on the play store. So you could check every day or every week if those 20 packages are still available. But at the end pushing a policy with unavailable package is not an issue.
Yeah, we see the same through our MDM, the relvant app(s) are just not provided anymore.
