Jason Bayton

Google is deprecating the Play Store for Work app browsing page

2026-04-18T12:33:30Z

Google is pulling the plug on the app browsing page within Play Store for Work. If you've been around long enough to remember the old app "Approval" flow, this was the page that supported it - and since that was deprecated back in September 2025, the browsing page has been largely redundant since.

After May 15 (extended from the original April 15 date), visiting play.google.com/work will redirect based on your organisation type:

Managed Google Play Accounts enterprises → the Admin Settings page (play.google.com/work/adminsettings)
Managed Google domains → admin.google.com
Everyone else → the Android Enterprise partners page

Worth noting, the Admin Settings page within Play for Work isn't going anywhere for managed Google Play Accounts enterprises - it's still needed for managing administrators, and will remain available.

For the majority of organisations leveraging the managed Google Play iFrame within their EMM for app management, this change will have no impact.

🛟 For help or guidance, feel free to reach out.

Android 15 blocks app installs targeting Android versions below 7.0

2026-03-13T18:09:56Z

In Android 15, Google incremented the security policy blocking the installation of old applications to include Android 6.0

What’s changing

From Android 15 it is no longer possible to install any application that targets an API level below 24 - Android 7.0. Attempting to do so will trigger a security exception.

Will this have any impact on EMM-deployed devices?

Yes. If a device is enrolled with, or upgraded to Android 15, it will no longer be possible to install old Android applications. Devices with apps already installed will not be affected.

Do my enterprise apps have to target API level 35 (Android 15)?

No. It's certainly better to ensure apps are targeting the latest API level where possible, but as long as applications target an API level of 24.(Android 7.0) or higher for Android 15, apps will continue to be able to install without issue.

Head's up

This new policy, like Google Play's targetSdkVersion requirements is expected to increase over time. See Android minimum SDK matrix for a full overview of requirements across Android versions, including test APKs.

Is it possible to test the changes?

Yes, on an Android 15 device you may connect to ADB and sideload an application with:

adb install name_of_package.apk

This will result in an error similar to:

INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 24, but found 22

To overcome this error and install the application anyway, use:

adb install --bypass-low-target-sdk-block name_of_package.apk

Note this only works via ADB, there are no other means of bypassing the SDK block.

View What's new in Android 15 for enterprise for details of this and other changes in Android 15, and for the technically-minded, here's Google's (Android 14) documentation on the change.

Read a topic discussing this further on the customer community.

Known issues with Pixel 9 and Android 15 for enterprise

2026-01-30T15:41:33Z

Android 15 launched officially for Pixel on October 15th.

I've been running through standard enterprise validation, ensuring to include the new Private Space feature given its cohabitation with enterprise functionality, and unlike Pixels of yonder, the enterprise functionality this year has led to more than one eyebrow raise.

If you're deploying Pixel 9 with Android 15 to your estate, here are some (non-exhaustive) issues to be aware of:

Heads-up

Unless otherwise stated, the issues described below have only been replicated on my Pixel 9 XL Pro. Other devices running Android 15 may be fine.

Undertake your own testing accordingly, and feel free to get in touch with feedback!

Company-owned managed profile and vital apps

Pixel Screenshots

Update Dec, 2025: I've received confirmation from Google that Pixel Screenshots is a permanent addition to an otherwise generally bloatware-free Pixel experience, and it is intended & expected to see this unnecessary application pop up in the work profile.

That's a disappointing outcome to a year-long support ticket, that remains open presently for Pixel Studio.

During the provisioning and setup flow, users are deferred to the setup wizard to add a personal account and set up their device normally. After the PAI screen offering Googles suite of applications, setup completes and apps begin installing & updating.

On update, both Pixel Studio and Pixel Screenshots find their way into the managed work profile. This is despite neither app being in the PAI list, they appear to update shortly after setup completes, and the act of updating is what triggers their arrival within the work profile.

Via policy the following also has no effect on the appearance of these apps within the profile:

{
    "packageName": "com.google.android.apps.pixel.agent",
    "installType": "BLOCKED"
},
{
    "packageName": "com.google.android.apps.pixel.creativeassistant",
    "installType": "BLOCKED"
}

It's unusual to see apps pop into the profile after provisioning, which suggests to me the vital apps config isn't to blame directly, but nonetheless, a configuration somewhere is leading to this:

https://www.youtube.com/watch?v=vmrL7WI2OmQ

For further clarity, updating these apps manually from Google Play after setup, if automatic setup is skipped/stopped for example, will result in the same behaviour. This confirms to me it is the act of pushing a new version of the app to devices, as until that happens these apps remain where they belong, in the parent profile.

Workaround

These apps can be disabled from the work profile with a long-press (from app drawer) > App info > Disable
Update policies targeting these apps may help, though that is untested.

Delegated scopes undetectable in the work profile

As of December 9th, this has been fixed by Android engineering

One affecting me directly as I spend more time adding delegated admin features to PACKAGE SEARCH and MANAGED INFO, it's seemingly not possible to fetch managed scopes from within the work profile in 15. I've tested this again in the company-owned work profile and personally-owned work profile deployment scenario. When calling:

val dpm = context.getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
val delegatedScopes = dpm.getDelegatedScopes(null, context.packageName)

~~The expected response if a scope has been delegated is [CERT_INSTALL] (for example). What returns instead is [].~~

In testing on a Pixel 6 Pro running Android 14, I faced no issue from within the work profile. Likewise on 15 this works perfectly fine from the parent profile, in a fully managed deployment scenario. It also works fine on the Pixel 6 Pro when updated to 15 as a company-owned device, but I can replicate it on personally-owned (BYOD), so it's something of an inconsistent one. Below are two Pixels, one on 14 and one on 15 leveraging the exact same policy as a company-owned work profile device:

Workaround

~~Nothing I'm aware of just yet.~~

~~This has been escalated to Android engineering.~~

Disappearance of distributed applications

This appears to have resolved, but no precise timeline of when.

~~After enrolment - once more in both company-owned work profile and personally-owned work profile deployment scenarios - applications appear to be vanishing:~~

https://www.youtube.com/watch?v=TDFH6JC6WOQ

https://www.youtube.com/watch?v=0pOyhODdSi4

~~In my testing, the application may return at a later point, but it risks disappearance once more when the policy updates.~~

~~The replication steps, if the video isn't your cup of tea, are:~~

~~1. Enrol a device into a company-owned/personally-owned, work profile deployment scenario~~ ~~2. Apply a policy. Initiall I was replicating this with Play Store model under personal usage policies, but I can replicate it without this on personally-owned work profile also.~~ ~~3. Installed applications in the work profile vanish.~~

~~Here's the policy deployed, this is via AMAPI:~~

{
  "name": "enterprises/LC01qtbcq4/policies/missingapps",
  "version": "1",
  "applications": [
    {
      "packageName": "org.bayton.managedinfo",
      "installType": "FORCE_INSTALLED",
      "managedConfiguration": {
        "customisation_settings": {
          "organisation_id": "testytesty",
          "enable_device_identifiers": true
        }
      },
      "delegatedScopes": [
        "CERT_INSTALL"
      ]
    },
    {
      "packageName": "com.google.android.apps.pixel.agent",
      "installType": "BLOCKED"
    },
    {
      "packageName": "com.google.android.apps.pixel.creativeassistant",
      "installType": "BLOCKED"
    },
    {
      "packageName": "org.bayton.packagesearch",
      "installType": "FORCE_INSTALLED",
      "delegatedScopes": [
        "MANAGED_CONFIGURATIONS"
      ],
      "userControlSettings": "USER_CONTROL_DISALLOWED"
    }
  ],
  "defaultPermissionPolicy": "GRANT",
  "playStoreMode": "WHITELIST",
  "advancedSecurityOverrides": {
    "untrustedAppsPolicy": "ALLOW_INSTALL_DEVICE_WIDE",
    "developerSettings": "DEVELOPER_SETTINGS_ALLOWED"
  },
  "crossProfilePolicies": {
    "crossProfileCopyPaste": "CROSS_PROFILE_COPY_PASTE_ALLOWED",
    "crossProfileDataSharing": "CROSS_PROFILE_DATA_SHARING_ALLOWED"
  }
}

~~Of 9 personally-owned work profile and 23 company-owned work profile deployments I've set up testing this, across two different, unique enterprise IDs, this has been consistently replicable.~~

~~### Workaround~~

~~None I'm aware of at the moment.~~

~~This has been escalated to Android Engineering.~~

Presence of dialler, messaging within the Private Space

This is resolved.

Not something I've been able to replicate reliably, but it does appear occasionally the above apps pop up in the Private Space, and they're not supposed to be there. Private Space has no inbuilt functionality for secure calls or messages (though that would be cool, perhaps via dedicated eSIM), and this is confirmed as the applications are mostly non-functional when interacted with.

~~### Workaround~~

~~None I'm aware of.~~

~~This has been escalated to Android Engineering.~~

Application of personal Play Store policies to the Private Space

As of Monday October 28, this has been fixed with a Google Play update

Another COPE issue, the documentation suggests personalUsagePolicies for personalPlayStoreMode that define application availability within the parent profile of a company-owned work profile device are also applicable to the Play Store within the Private Space.

~~In my test case, I have applied personal use policies to my Pixel 9:~~

"personalUsagePolicies": {
    "personalPlayStoreMode": "ALLOWLIST",
    "personalApplications": [
        {
            "packageName": "org.bayton.packagesearch",
            "installType": "AVAILABLE"
        }
    ]
},

~~Unfortunately the policy doesn't apply. This GIF shows the correct application in the personal Play Store, but the Private Space Play Store does not respect the policy applied.~~

Workaround

~~Don't permit Private Space until this is fixed, if this is a concern. This is with Android Engineering, and a Google Play update is expected to resolve this in due course.~~

Reinforcing the need to test & validate

It's not unusual to find issues with new releases, and these examples prove yet again the importance of testing and validating all of your organisation's managed device use cases before rolling out a major release or brand-new device.

🛟 For help or guidance, feel free to reach out.

Google sunsets Google Play Services on Android Lollipop (5.x)

2024-08-04T21:19:44Z

Google has ended support for Google Play Services on Android Lollipop 🍭.

At 10 years old, it's well past its usable life, but the ~1% of active devices still running 5.x today - if not upgraded to a later version - will no longer receive what is considered the last remaining olive branch from Google offering compatibility and functionality as a provider of both first-party services, as well as SDKs & libraries for app support within the ecosystem.

Android 5.0 was a pivotal release for Android. While most will know it for the introduction of Material Design, it was the release that introduced Android for Work and the work profile through the integration of Divide (throwback video below!).

Any organisations still using certified Lollipop devices must move to a later Android version to ensure continued support and stability of corporate apps & services.. if the loss of security updates, kernel support, and app support already weren't reason enough.

https://www.youtube.com/watch?v=SX3Nw-eiPTM

🛟 For help or guidance, feel free to reach out.

Zero-touch API error 403 caused by new TOS

2024-05-25T17:25:54Z

As first raised in the Customer Community here, the customer zero-touch solution has a new terms of service published, which will cause the Customer API to throw an error 403 (unauthorised) until it is accepted, per this reference.

To resolve this, an admin or owner must log into the zero-touch customer portal and accept the new ToS.

🛟 For help or guidance, feel free to reach out.

Google Play System updates (mainline) are no longer managed by System Update policies

2024-04-17T20:44:28Z

As of early April 2024, Google Play System Updates, or Mainline updates as they're also known, are no longer managed by system update policies.

With system update policies set (automatic, window, postpone, freeze), GPSUs will revert to their unmanaged behaviour.

Check the techdoc for more info.

🛟 For help or guidance, feel free to reach out.

Android will not permit install of very old apps from 14

2024-04-10T22:37:58Z

From Android 14 it is no longer possible to install any application that targets below API level 23 - Android 6.0. Attempting to do so will trigger a security exception. Applications already installed will remain untouched, however new installs on any device that hasn't previously had the application will fail.

Be sure to update your applications to target a recent API level (or at least 6.0) before deploying any Android 14 devices into your estate. This will become a rolling policy, incrementing an API level with every future release.

Check the techdoc for more info.

🛟 For help or guidance, feel free to reach out.

CVE-2024-0519, Chrome for Android

2024-02-01T20:12:20Z

Google has recently patched a known and exploited vulnerability in V8, the JavaScript engine. According to NIST:

Out of bounds memory access in V8 in Google Chrome prior to 120.0.6099.224 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)

NIST: https://nvd.nist.gov/vuln/detail/CVE-2024-0519

Chrome for Android release: https://chromereleases.googleblog.com/2024/01/chrome-for-android-update_0556626765.html

Chrome for desktop release: https://chromereleases.googleblog.com/2024/01/stable-channel-update-for-desktop_16.html

This is patched as of Chrome for Android version 120.0.6099.230.

Recommended actions

It is not stated how this vulnerability directly impacts Android devices, however Chrome for Android does incorporate the patches released prior to the desktop versions, and is therefore reasonable to err on the side of caution.

Due to the nature of the vulnerability, it is recommended EMM admins set Chrome for Android (or equivalent Chromium-based alternatives) app update policy to high priority, this will download and install the Chrome for Android update as soon as possible, ignoring all normal update constraints.

In AMAPI this is done by setting AutoUpdateMode to AUTO_UPDATE_HIGH_PRIORITY, but as labels in EMM platforms are inconsistent, look for settings within an assigned app to set an app specific update mode. Note by doing this, users may experience closures of Chrome while in use, per normal update expectations.

Alternatively, you may consider applying a minimumVersionCode policy with the code 609923033 for version 120.0.6099.230, or 609923133 to bump to version 120.0.6099.231 (a version above that which is patched) however be aware Chrome version codes vary, per Google:

Different build variants of Chrome for Android have different version codes

via

The above version codes are associated with the ARM64 builds of Chrome for Android and 10+. They are not the lowest version codes available for these versions of Chrome for Android.

Ensure appropriate testing is undertaken if choosing to use a version code policy, and be aware it is a highly disruptive policy that will prevent device use until the app is updated.

🛟 For help or guidance, feel free to reach out.

Samsung zero-touch enrolment resolution

2024-01-29T14:37:04Z

Following earlier reports of zero-touch enrolment failing for Samsung devices running OneUI 6/Android 14, Samsung last week updated their KB with details of a temporary resolution, with a permanent fix to come through OTA at a later date.

As of January 22nd, 2024, Google has implemented a server-side update to temporarily resolve this issue. The affected devices can now be enrolled through zero-touch enrollment.

Samsung is preparing a One UI 6.1 firmware update that includes the updated Google Play Service (GmsCore) app to permanently fix this issue. The One UI 6.1 update will be available as a software update to the affected devices.

This was previously covered here.

🛟 For help or guidance, feel free to reach out.

Deprecation of the old managed Google Play iFrame app approval flow

2024-01-29T14:37:04Z

Be aware, a year after Google deprecated the old app approval APIs, EMMs are now switching over to the new flow. This does not impact AMAPI-based EMMs, with the exception of Intune.

Admins will no longer see an approve button for applications in the managed Google Play iFrame, and will instead see a select button instead.

SOTI and Intune announcements for reference. Note, customers may have to upgrade their EMM version if using a locally hosted solution, to avoid a disruption to functionality later this year.

More info

🛟 For help or guidance, feel free to reach out.

Major Android 14 bug permanently applies management restrictions

2024-01-29T14:37:04Z

Google has acknowledged an issue with the management of Android 14 devices that renders restrictions applied to devices irremovable once set unless unenrolled and re-enrolled.

It's a significant issue for both upgraded and factory-shipped Android 14 devices with no current fix.

Unfortunately even when a fix does roll out, impacted devices will remain impacted, based on current information, and will still require re-enrolment to resolve their stuck state.

There's no public Customer Community service announcement detailing the issue at the moment, however VMware have gone into great detail on this issue, down to the degree of which configurations are affected specifically, linked below.

For now, it is advised to avoid upgrading and/or deploying 14 unless you're willing to accept a re-enrolment for policy adjustments at a later date. In any case, take the time now to review policies and ensure they're as you intend them to be for your Android 14 estate, they may be stuck this way for a while.

🔗 https://kb.vmware.com/s/article/95776

Update: Public customer community announcement:

🔗 https://www.androidenterprise.community/t5/service-announcements/in-progress-some-management-policies-are-made-permanent-on/ta-p/1494

🛟 For help or guidance, feel free to reach out.

Jason Bayton

Google is deprecating the Play Store for Work app browsing page

Android 15 blocks app installs targeting Android versions below 7.0

What’s changing

Will this have any impact on EMM-deployed devices?

Do my enterprise apps have to target API level 35 (Android 15)?

Is it possible to test the changes?

Read more

Known issues with Pixel 9 and Android 15 for enterprise

Company-owned managed profile and vital apps

Workaround

Delegated scopes undetectable in the work profile

Workaround

Disappearance of distributed applications

Presence of dialler, messaging within the Private Space

Application of personal Play Store policies to the Private Space

Workaround

Reinforcing the need to test & validate

Google sunsets Google Play Services on Android Lollipop (5.x)

Zero-touch API error 403 caused by new TOS

Google Play System updates (mainline) are no longer managed by System Update policies

Android will not permit install of very old apps from 14

CVE-2024-0519, Chrome for Android

Recommended actions

Samsung zero-touch enrolment resolution

Deprecation of the old managed Google Play iFrame app approval flow

Major Android 14 bug permanently applies management restrictions