Android 15, Android 16, and the New Rules of Dedicated Device Management

Every Android release feels a little different depending on where you sit. For consumers upgrading their personal Pixel, a new version often means a redesigned quick settings menu, a refreshed look, or maybe a battery improvement. For IT operators, though, the same release can land very differently.

When Android 15 started hitting tablets and smartphones — especially consumer devices with Google Mobile Services (GMS) — the changes were immediately felt in enterprise use cases. Password fields disappeared from remote-control sessions. Old service behaviors IT teams had relied on for years stopped working. What looked like a minor version bump for a consumer became a major operational challenge for a dedicated fleet.

That’s the dynamic operators need to understand. The dessert jump from Android 13 to 14 may not have rocked the boat for consumer GMS devices used in dedicated settings, but the OTA to Android 15 is a different story. And the real wave hasn’t even hit yet. Once vertical market OEMs — Zebra, Honeywell, Lenovo, Bluebird, MicroTouch — begin shipping devices based on Android 15, these changes will arrive in stores, restaurants, warehouses, and clinics all at once. IT teams need to get their Android device management strategy ready now, not later.

This is also part of a broader pattern. As Android Enterprise industry expert Jason Bayton recently outlined in his deep-dive on Google Play developer verification, Google isn’t just tightening the rules on device behavior. They’re also raising the bar on who gets to publish apps and how those apps are trusted. Developers face stricter verification; IT operators face stricter device controls. Together, these changes are reshaping Android into a more locked-down, consumer-first ecosystem.

That’s the context for Android 15 — and for Android 16, which is now almost gold. The two releases aren’t just incremental updates. They’re a turning point in how Android behaves in enterprise. And for IT operators and OEMs supporting dedicated fleets, the choice of whether to run AOSP or GMS — and which mode of management to rely on — has never mattered more.

Two Flavors of Android: AOSP and GMS

To make sense of these changes, it helps to remember that “Android” is really two different worlds.

AOSP Android is the open-source core. It’s the foundation on which many OEMs build vertical market–specific devices, and of course, what Esper uses for our Foundation for Android specialized OS build. AOSP 15 and 16 bring platform hardening: stricter service rules, PendingIntent behavior, permission allowlists, and protocol updates. These are universal and apply regardless of whether Google services are present.

GMS Android layers Google Mobile Services on top of AOSP. Along with the Play Store and Play Protect come new policies designed primarily for consumer safety. This is where password fields get masked in remote control, Private Space appears, Circle to Search gets locked down, and new security defaults quietly arrive in the name of protecting individual users.

That difference explains why a fleet running Esper Foundation behaves predictably while a fleet of Samsung tablets suddenly starts hiding passwords in remote sessions. Same Android version, radically different operational outcomes.

The World According to Android 15

Android 15 introduced changes that directly impact dedicated use cases:

Remote control blind spots On GMS builds, sensitive content like password fields and OTP prompts are masked during RC sessions. On AOSP builds, you still see them unless the app itself sets FLAG_SECURE.

Foreground Services got stricter Historically, IT teams relied on boot-complete tricks: when a device rebooted, a DPC or agent could catch the BOOT_COMPLETED broadcast and immediately spin up background services like remote control listeners, kiosk lock controllers, or telemetry reporters. Android 15 changed the rules — certain service types (camera, MediaProjection, data sync) can no longer be started this way. This applies universally in AOSP and GMS.

PendingIntents were canceled in stopped state Many fleet agents used watchdog flows: scheduling a PendingIntent to restart a service or relaunch an app if it crashed or was killed. Others used them for self-healing routines, such as restoring kiosk mode after a forced exit. On Android 15, those PendingIntents are wiped when the app enters the “stopped” state. Again, this applies across AOSP and GMS.

Signature permissions restructured Being platform-signed is no longer always enough. Starting with Android 15, AOSP introduces a signature-permission allowlist mechanism:

• System apps (platform-signed and shipped in the system image) continue to receive the platform signature permissions they have historically requested. However, if a system app is updated and begins requesting new platform signature permissions, those new permissions must be explicitly allowlisted in the system configuration.
• Non-system apps (platform-signed but installed outside the system image) now require explicit entries in the allowlist for each platform signature permission they request. Without them, the permissions behave as if the app weren’t platform-signed—at least on production (non-debuggable) builds.
  

This is a core platform change that applies to both AOSP and GMS devices. The difference is in who manages the allowlist:

• On AOSP builds such as Esper Foundation, the allowlist is defined as part of the OS build process. Fleet operators can be confident that their management agents and trusted apps are properly listed.
• On GMS OEM builds, operators depend entirely on the OEM to maintain and test the allowlist. If the OEM omits an entry, the agent won’t receive its expected elevated permissions and troubleshooting quickly becomes an escalation exercise with the vendor.
  

Networking and UI behavior shifted TLS 1.0 and 1.1 are now disabled — TLS 1.2 is the minimum. Apps with targetSdk lower than 24 (Android 7.0) can no longer be installed. And edge-to-edge rendering is now enforced for apps targeting API 35: this means apps must properly account for system bars and insets. For dedicated device UIs, if you didn’t pad correctly, your navigation or action buttons might end up hidden behind the system bar.

OEM-specific impacts Samsung restricted Knox Remote Control APIs to Device Owner mode with explicit authorization — which is not a problem for Esper, since Esper always runs in Device Owner. Other OEMs like Zebra, Honeywell, Lenovo, and Bluebird exposed new controls through OEMConfig. These controls help with scanners, buttons, and lockdowns, but they aren’t removing the GMS-imposed barriers to RC visibility.

The upshot: Android 15 reset long-standing assumptions about signature permissions, how services start, how watchdogs behave, and what RC can see.

The Shape of Android 16

Android 16, almost ready for release, continues the trend.

• Connectivity controls: Admins can now block Thread networks and fully manage NFC state. For IoT-heavy fleets, this closes off vectors, ones that operators often had little control over before.
  
• Provisioning refinements: A smoother setup flow and expanded eSIM support simplify onboarding and reduce manual steps. This is about efficiency — not a minefield — but operators who built brittle custom flows will need to retest.
  
• Security enhancements: “Advanced Protection” for high-risk users and biometric checks for actions outside trusted locations raise the bar on user identity, though today these are primarily user-facing features.
  
• UI productivity: Material 3 refreshes the look and feel, Live Updates standardize persistent notifications, and early desktop/tablet modes hint at broader device versatility.
  
• Platform mandates: Apps targeting API 36 must support large-screen resizability. Legacy kiosk apps may need updates to handle this gracefully.
  

Some of these changes are universal (AOSP + GMS). Others — especially around privacy and user-facing protections — are GMS-only. Yes, the differences between AOSP and GMS widens.

OEMs in the Middle

OEMs are now in the hot seat. Their choices determine how smooth or painful Android 15 and 16 feel for operators.

• Samsung provides Knox APIs that preserve RC, but with stricter gating. Again, not an issue for Esper because Device Owner is our default.
  
• Zebra, Honeywell, Lenovo, Bluebird extend control through OEMConfig. These extensions are valuable for dedicated hardware features but do not alter Google’s GMS-imposed behaviors.
  
• Esper Foundation avoids the consumer-first GMS policies entirely. Starting from AOSP, it captures Android’s security hardening while insulating fleets from sudden consumer-driven surprises.
  

Device Owner: The Bedrock of Control

With Google adding more cloud-first policies, it’s tempting to believe that cloud-native management is the inevitable future. But Device Owner remains the bedrock of enterprise control.

• It works across both AOSP and GMS.
  
• It supports OEM extensions that fleets actually depend on.
  
• It enables scenarios outside Google’s roadmap — like Android on x86, which Esper Foundation supports directly.
  

For IT operators, Device Owner isn’t second-class. It’s the only mode that delivers predictability across fragmented Android landscapes.

At a Glance: Android 15 and 16 in Dedicated Fleets

Upcoming Desserts…

From developer verification to device policies, Google is locking down Android more tightly than ever. For consumers, that’s a win. For IT operators, it’s a shifting landscape. And while the changes are public and well-documented before each release, the impact on dedicated fleets is still profound.

The right response isn’t panic. It’s preparation. Know the difference between AOSP and GMS. Choose OEM partners who extend meaningful controls. And above all, recognize that Device Owner remains the enterprise-grade authority. With Esper Foundation for Android, operators can embrace platform security hardening without being blindsided by consumer-first surprises.

Android isn’t standing still. Neither should enterprise strategy.