Is there any way to disable Google Play Protect (GPP) from an EMM or to otherwise whitelist apps from scanning?

[mattdermody]

I am very concerned about the Enhanced GPP features coming soon that are currently being piloted in other regions.

https://security.googleblog.com/2023/10/enhanced-google-play-protect-real-time.html

This is not a welcome feature whatsoever for the fully managed space where we have business apps written internally that are being installed on business devices, owned by that business. In no way do we want Google sitting in between deciding whether a very legitimate app written internally for an organization should be installed on devices that are purchased and owned by the same organization on fully managed devices. I would like a way to disable GPP completely, or at a minimum whitelist applications from scanning as we don't want Google interfering in the business operations. 

GPP is a helpful consumer protection features but fully managed devices should have the ability to be opted in or out of the program. Otherwise GPP can incorrectly flag a mission critical app and disable or remove it from a device, thereby bringing down a line-of-business application and an end customers operations. While the intentions of GPP are good, by blocking business apps Google themselves is becoming the malicious actor that GPP is ironically trying. to prevent. 

[karam]

Could just be ignorance on my part, for which I apologise, but the frustration arose when I could see an option (blue slider button style) to turn off GPP from its settings and a pop up asking whether to turn off or cancel would come up, but even if I clicked on the turn off option it just wouldn't actually do it - not even any error message to say why. What's the point of showing it as a changeable setting when it can't change was the frustration. As others have said, no problem if you want to have protection for apps through the Google Play channel, but for various reasons it is often the case where Android is used to implement a dedicated device that you don't want the risk of application instability (or becoming vapour ware) due to some unsolicited intervention

[RickB]

This is happening to most of our enterprise apps, and Google is not at all helpful in discovering why. Regardless, enterprise apps should not be subject to Google's paranoia. All it is doing is causing enterprises like my own to have to turn the feature off, because of the numerous false positives.

[Lizzie]

Thanks @karam and @RickB for sharing a bit more detail.

I am interested to dig a little deeper into this, and I'm sorry if you haven't had much luck providing this feedback before. RichB you mention that this is happening with most of your enterprise apps, so potentially there is a common theme among them that is failing and it sounds like the notification/information provided doesn't help much to troubleshoot why this is happening? Do you think that better information/guidance at this point or before you make them available to end-users would potentially help here? 

Thanks again,

Lizzie

[RickB]

Every day Google Play Protect decides it doesn't like 3 or 4 more enterprise apps. This is out of control. These are Corp owned devices! Stop messing with things you knonw NOTHING about

[JamesKnight]

Hi Lizzie. Thanks for responding.

My experience relates to an in-house app and, therefore, something which Google won't have (and don't need to have) knowledge of. 

I appreciate Google's desire to protect consumers and I have no problem with GPP scanning apps downloaded from the Play Store (or other sources) when the device is not managed within a corporate environment.

However, Google should absolutely not be dictating - or even influencing - whether or not to allow a company's own app to be installed on devices which it owns and manages.

Our app is developed internally, exclusively for our own use. It is not available on the Play store (or any other store) and is installed via an MDM solution (Soti MobiControl). Under those circumstances, GPP should have no role, at all,  and we should be allowed to have control over our own devices and make our own decisions on risk.

MDM solutions should be able to switch off GPP on company-managed devices, either globally or on an app-by-app basis.

I hope this helps.

Thank you.

[mattdermody]

👏👏👏☝️☝️☝️

Spot on.

[benoit]

Hi,
New to the discussion, as it is becoming the exact same challenge for our customers too.
Did you manage to have any action done to solve that issue in your private discussion?

Note in our case:
Targeting SDK higher than 32 is currently impossible due to the programmatic bluetooth restrictions that are a key feature.

Cheers

[mattdermody]

The Android team was willing to listen and was receptive to the feedback provided but we are a long way away from any changes for this being implemented. I would not count on any changes relative to GPP administration or allow listing any time soon and would figure out alternate strategies in the mean time. 

[tbrowne]

I want to echo what has been said especially by JamesKnight and mattedermody.

This has started to become very disruptive to our operations recently and I would appreciate a response from Google on this.

[Michel]

I'm joining this discussion as well. I see a lot of issues with existing customers of us where this could cause a lot of issues. 

[Lizzie]

Hello everyone,

Thanks again to those of you who have shared your experiences and thoughts on this threads previously and more recently. I really appreciate the insight you are sharing with us and I think it is clear that this is an important area for many of you. 

As mentioned before I am keen to understand more of the specifics and if there are any patterns to the types of apps that are getting flagged, this way we can better highlight this back to our product team. 

I've tried to arrange a call with a couple of you to discuss this further and so far we haven't managed to arrange this. As there are more people in the conversation now, I wanted to open up this to others as well, to see if any of you might be able to spare the time and would be interested in speaking with me and some of my teammates to understand this a little more? (I understand you are all very busy people, so thank you, thank you).

Thanks,

Lizzie

[RamShear]

Hello, I'm new to this conversation but found it because I've having this issue with Apps being yanked off our devices.   I don't have the same chops many of the other posters have when it comes to Android, I've mostly been managing iOS devices via MDM for the past several years, but we were purchased last year and now I'm scrambling to learn both Intune and Android.

In our case, we use a third party software product that has a couple mobile apps available from within it.   Their apps are not on the Play Store because one of their customers pushed the APKs out to a private Play Store instance and Google won't let the same APK exist in different Play Store environments (this is what the software vendor tells me).

We set a policy in Intune to allow sideloading for this one group of users, and that works -- they can sideload the apps.    But the app gets deleted without fail.  It just pops a notification with the App name and says "Deleted by your admin"

We've combed through every compliance policy and conditional access policy in Intune we can find.  I've even gone so far as to exclude the user group from each policy that applies to it to see if that policy is the one causing the removal, but it always removes.   On my test device, I can look at "Play Protect settings" and the option for 'Scan apps with Play Protect' is switched off, but that app still gets removed.

Now I'm mad at everyone.  I'm mad at the software vendor because they really ought to fix the problem on their side and publish the #$%& apps to the Play Store.   I'm mad at Intune because there's nothing in their logs that tells me what on earth is initiating the removal process.   I'm mad a Google because the device does not log the process that initiates the removal either -- and frankly, we should be able to push the APKs to a private instance for ourselves but we can't.

[mattdermody]

I can certainly relate to a lot of the frustrations that you're having with the Android Enterprise system combined with your usage of Microsoft Intune. With that said, it sounds like the issues that you're experiencing with sideloading apps is not necessarily a GPP issue. This seems to be proven out by the fact that even when manually disabling the GPP feature on your test device it still gets removed. I think this may be more evidence of Intune actually removing the sideloaded app versus it being GPP preventing the app from being installed in the first place. 

While it is true (and frustrating) that only one instance of a particular app Bundle ID can exist across all Google Play servers including both Public and Private distribution channels, your app developer should still be able to compile a new version of the same app under a new Bundle ID so that it can be uploaded into Play. If I were them I would compile a new Bundle ID and then upload that into my own Developer Console of Google Play as a Private app and then grant your organization ID access to that Private Play app. This way they only have to change the Bundle ID of their app one time and be able to grant Play distribution to any approved organizations. If they otherwise build a custom compile with a new Bundle ID and provide it directly to you then you will upload it into your own Private Play store through the Google Play iFrame and effective consume that Bundle ID as well. This would translate to them having to provide you with your own custom compiled Bundle ID for every single new version of the app.  I can understand their reluctance to avoid that sort of scenario because it adds additional overhead to every single new version release as they'd potentially end up having to compile different versions for every customer that they have that is limited to only using Google Play for app distribution to their devices. By creating a new Bundle ID that they upload into their own Private Play store they can reserve that ID and only have to fork their compile process one time. This is a somewhat reasonable ask to put back on them. Note however that this will also translate to the developer having to manage the release tracks for each new version of the app that you need delivered which does still put additional overhead on them. This could be another reason that they're pushing back on your request. 

Note that your developer is likely pushing back on this because you're using an EMM (Intune) that ONLY supports installation of apps via Managed Play as a baseline lowest common denominator function of Android Enterprise Management standards. Other more capable EMMs extend beyond the capabilities of AMAPI with a custom DPC and these EMMs offer the ability to install APKs directly on fully managed Android Enterprise devices without the restrictions and limitations of having to pass your app install through Managed Google Play. For mission critical / line-of-business Android apps this is still the approach that I recommend. Google Play based app distribution is otherwise still too limited when it comes to version control, roll back, granular installation scheduling etc for mission critical apps, in my opinion. My guess is that your app developer shares a lot of these same opinions and are ultimately trying to protect you from these risks by expecting you to have an EMM capable of direct app installation with proper control. You are taking their frustrations out on them when in reality you should be frustrated that Google hasn't provided a complete set of comprehensive installation controls necessary to support line of business devices and Intune has effectively aligned their strategy completely with Google by not offering you any additional capabilities.  

[Timmy]

The app gets removed on the device because you have not added it as an "Android Enterprise System App". When you sideload apps you need to assign that to the device and if you don't it will get removed by the system. 

https://learn.microsoft.com/en-us/mem/intune/apps/apps-ae-system

[davidguill]

Hi @Lizzie, 

Has anything been officially announced on this yet by Google?  I am being asked for this control by several customers but being told by the EMM developers that it's still not possible in Android 15 even after sharing the links provided by @jasonbayton.  

Thanks All

David

[jasonbayton]

It was added to the Android Management API in the last hour 🙂 

[mattdermody]

Is this actually the same thing as an allowlist for bypassing GPP scanning? Are ON Device Abuse Detection (ODAD) and GPP equivalent? It sounds to me like two different but possibly related features.

[jasonbayton]

No so this is the phishing protection specifically, general GPP is not even in the works as far as I know 

[davidguill]

So this doesn't really help with the issue of installing corporate apps that are flagged incorrectly.  Was really hoping this would be addressed in Android 15. 

[BenMcc]

Sorry if this has been posted already (did look but didn't see) but you can prevent the apps from being flagged by Play Services/Play Protect by filling in this form: https://support.google.com/googleplay/android-developer/contact/protectappeals even if the app isn't on Play.

Not ideal but it will get around the issue partly.

Ben

[davidguill]

Thanks for the tip, unfortunately this won't help a lot of our customers as they have closed networks

[melanie · Accepted solution]

Hi all,

My name is Melanie and I am a Product Manager on the Android Enterprise team. Lizzie highlighted your discussion here back to our team. Thank you for your feedback and the useful discussion.

Reading through your feedback, we’ve picked up on a point that was consistently mentioned around private company apps being scanned, so we wanted to provide you with some additional information around this.

Google Play Protect (GPP) is designed to help protect against malware. By default, GPP asks users to send unknown applications to Google for scanning. This is because apps installed via Google Play or Managed Google Play are already scanned, but applications side-loaded (including installed through EMM installers) are not.  This is what triggers the "Send app for a security check?" dialogue.

Several of you mentioned you would prefer not to send private company apps, especially on company-owned devices, externally to Google servers. The servers involved in this processing are kept isolated and protected within Google, but we still acknowledge that some organizations may prefer not to upload any data to external servers. 

Additionally, we acknowledge that the “Send app for a security check” message can be confusing to device users, especially as they may not be the app or device owners and are therefore unable to make a decision on this.

Based on all of your feedback you’ve provided, last week we made a change preventing unknown applications (e.g. private side-loaded apps) from being uploaded to Google servers on Fully Managed devices or Managed Work Profiles.

Please note that GPP is still running on these devices as usual, and is still comparing these apps to known PHAs. (So if an app is highly likely to be a PHA, users will still see the "Harmful app blocked" dialogue.)  We’ll be updating our GPP Help Centre article shortly to reflect this change.

This change went live across all online devices on September 6th.

Thank you once again for your feedback and we look forward to hearing more across the community conversations. If you have any additional questions on this, please do feed them via Lizzie. 

Melanie

[Lizzie]

I'd also like to add a special thanks to @mattdermody for starting this topic and also for taking the time to join a call with myself and a couple of members of our team. 

I know this is just a starting point, as much has been mentioned above, but I wanted to highlight Melanie's update here and also add my thanks: @jasonbayton, @BenMcc, @ian, @davidguill, @Timmy, @Michel, @RamShear, @tbrowne, @benoit, @JamesKnight, @RickB, @karam, @crystal11232, @davidguillaume 

[jasonbayton]

Holy moses what a result! Thank you @melanie & @Lizzie 😁.

I look forward to understanding how this functions behind the curtains 🙂

[mattdermody]

This is an amazing and honestly unexpected result! Thank you so much for hearing us out on the request and taking action. This is a great success story for this community.