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

Out of curiosity, how do you distribute your internally developed apps. 

- Manually adding the .apk to the deviec and installing it ?
- Uploaded it to the "Private app" section in Managed Google Play ?
- Created a Google Play Developer account and made the app "Private" and distributed it through those channels  to the organization ? 

Are you using any EMM for management of your devices ? 

Without knowing, my best guess would  be that depending on how you distribute the app you might see different results. 

That would be an acceptable solution to this as well! I wouldn't mind some sort of allow list or ignore list however to tell GPP which apps it can safely ignore from scanning. That way we could still leave it enabled for its benefits while not risking accidental flagging of mission critical business owned apps on business owned devices.

This would be an acceptable fix. 

If we have DO permissions on the device, it seems that whatever has DO permissions should own what is on the device - including the applications. The owner should be able to see the applications on the device and flag them saying "yes, that's mine - don't touch it." 

Don't hold your breath, GA is many months away 😅

There are very limited options available. You could disable Google Play Protect on the devices in order to avoid your legitimate business apps from being scanned or flagged. Doing so is unfortunately a manual operation per device as it has to be manually toggled off and is not controllable via EMM. If you're not using Google Play for any app distribution you could also disable Google Play completely. That's something that you should be able to accomplish from your EMM. With Google Play disabled you won't get updates to system components like the WebView, which your app might be reliant on. Then again, you won't get unexpected updates to these same system components which could just as easily jeopardize the stability of your apps. 

You might be able to file an appeal with Google to perhaps prevent your applications from being removed, however I don't think that they will tell you exactly why your app was being removed on GPP.  You will likely need to make sure you're following best practices on your application.  

You can file an appeal here: 

https://support.google.com/googleplay/android-developer/contact/protectappeals?sjid=3396504988404039213-NC

I'm sorry. I will focus on maintaining the professional decorum moving forward. 

What you're seeing here is just mounting frustration with the rise in consumer protection features in Android that are constantly imposing on the fully-managed business owned device use case. I absolutely understand why features like GPP exist. Android struggled with an early bad reputation of being "insecure" and "fragmented" and as a result there has been a constant push to dispel those perspectives. Every year there are more and more consumer protection features added into the base OS and that is generally a good thing for the ecosystem. The issue is when these features do not properly account for all of the management use cases. It is my opinion that when we have a device enrolled under Device Owner management that we have properly declared that the device is owned by the business which therefore should have every right to manage and utilize the devices how they see fit. Despite that, these consumer protection features also bleed into the Device Owner world, leaving enterprises to deal with figuring out how to disable them or work around them. There are many examples that come to mind:

- GPP app scanning of legitimate business apps. In the absence of being able to disable GPP we should be provided a mechanism to whitelist specific apps from scanning. 

- Scoped storage file restrictions also impacting Device Owner DPCs. Device Owner DPCs should have been able to manage files under scoped storage.  

- Doze Mode, Green Mode, Battery Optimization. Great for consumers, terrible for line-of-business devices

- Google Assistant accessible from a long press of the home button, even with a lockdown applied

- Uncontrollable updates to critical system components like the System WebView. 

- Managed Play updates requiring criteria like the device having to be in a charging state, when many line-of-business devices utilize hot swappable batteries so the devices may never be in a "charging state"

My end customers have now gone through numerous annual Android OS migrations on their devices and with each new version its like were playing a game of "whac-a-mole", figuring out which new consumer grade features have to be suppressed, disabled, or otherwise worked around. I regularly get the question of what new features they can expect when they are inevitably forced to upgrade and the list of pain points often is much longer than the list of benefits. My clients are going tired of these annual Android OS upgrades because they take a stable, mission critical, device environment and disrupt them, sometimes for several months until all of the new issues are taken care of. We then get some period of relief and stability before the next Android OS upgrade disrupts it all over again but even the periods of stability are often interrupted by uncontrolled updates to system components that break business app functionality. It's incredibly painful to tell a CIO that his production was shut down by a forced update to Chrome or WebView from Google Play that we otherwise could not have controlled, don't have version lock in, and can't easily roll back. 

I am not naive however, and completely understand the fully managed / Device Owner use case is the smallest use case for Android. We however feel constantly neglected. I had a large customer with 10k+ Android devices that migrated off of Windows CE recently tell me that they weren't sure if they owned their devices, or Google did, in reaction to numerous issues that they regularly experienced. It's not great when customers are thinking back about how great they had it in comparison on Windows CE. Sure Android is more secure now, and you'd be crazy to actually want to go back Windows CE, but there is something to be said about stability, predictability, and comprehensive control, etc and in many cases the end customers of the devices would likely stack rank those above security.

Why are security measures put in place in the first place? To prevent bad actors from performing malicious activities that could jeopardize the stability or functionality of the technology in the environment. It's therefore a bit ironic when these very security measures are what are resulting in instability and the breaking of production level functionality. 

Hi Lizzie, thanks for replying. 

I'd like to echo Matt's comments.

Whenever Android rolls out a new operating system update, it is a scramble to comprehend its implications for both us and our customers. The introduction of features outside the regular yearly OS release schedule are an even bigger scramble, as we're tasked with managing all our tablets deployed in the field that will receive these updates. I would love to go to our Android Enterprise settings to manage new features that come out of the new Android OS, but it feels like we’re stuck with no way to modify new Android features or settings.

While I acknowledge Google's responsibility to safeguard end-users, these very features can sometimes have adverse effects on companies utilizing managed devices, leaving businesses unable to programmatically enable or disable certain functionalities. Consider two examples:

1. Special permissions granting: Tasks such as granting accessibility or enabling "appear-on-top" functionality necessitate manual intervention on the device to approve permissions. Guiding an end-user through this process on a tablet can be cumbersome, prone to errors, and frustrating. Oftentimes, conversations with customers reveal their realization that an app requires special permissions, which we are unable to grant automatically. This dilemma usually results in either the company deciding against deploying the application or doing so at a sluggish pace, involving hands-on devices to manually grant those permissions. Neither of these options offers an optimal user experience.

2. Google Play Protect (GPP): Pop-ups displaying "Unsafe App Blocked" for mission-critical applications, even if bypassing the block is permitted, sometimes raise concerns among our end-users. The current workaround involves manually disabling GPP on each device, a less-than-ideal solution due to the number of manual steps (eight) required for every single tablet. Moreover, this approach is reactive, triggered only after the GPP pop-up occurs. Consequently, we find ourselves in a position where we must either proactively inform our customers about the significant impact of the latest Android version on their environment, lag behind in supporting the newest Android versions, or devise engineering workarounds to address the features introduced by Google.