Google released Android 17 on 16 June 2026, and several of its changes land directly on managed devices. According to Google's list of Android 17 enterprise features, administrators get new controls for AI automation and a runtime permission for local network access. Certificate Transparency is now on by default, and loopback traffic between work and personal profiles is blocked. Much of it can be set by policy in advance. Certificate Transparency needs a look at your in-house apps.
When we covered Android 16 for Enterprise in 2025, most items were new options that IT could switch on. The Android 17 list is shorter, but more of it changes default behaviour, and a default reaches devices whether or not anyone has touched a policy.
Oliver Schiemann and Magnus Wonschik put these changes in context in our webcast “What’s new in Android 17 for Enterprise?” (in German) on 11 June 2026, a few days before the release. The recording is free after registration, like the others in our webcast overview.
Android 17 is API level 37. The changes that matter for device management fall into three groups:
Google's enterprise page was last updated on 16 September 2026.
Yes, on corporate-owned devices. Android 17 introduces a framework that lets AI agents automate app workflows, and Google blocks that automation inside work profiles. On fully managed devices and in the personal profile of COPE devices, administrators can switch AI automation off entirely using the existing setNearbyAppStreamingPolicy.
A second pipeline passes device-level data to on-device agents. Authorised assistant apps receive that data through the App Functions framework. It returns nothing from work profiles, and administrators can disable it globally with setAppFunctionsPolicy and the flag APP_FUNCTIONS_DISABLED.
For BYOD with a work profile, the work side is protected by design and the personal side stays the user's decision. On corporate-owned devices the decision sits with you. In our Android 17 webcast, the speakers described the work profile as the barrier that keeps work data in place. Their advice: check which connections are possible from inside the work profile and block them where needed, for example with a URL filter when the work profile runs over VPN. It belongs in the same policy review as any other restriction, and your UEM has to expose both policies before you can set them.
Because Certificate Transparency is now on by default. If an app targets Android 17 (API level 37) or higher, CT verification applies to its network connections; on Android 16 apps had to opt in (Google, behavior changes). Google warns that connections relying on private or internal certificates may fail unless those domains are explicitly opted out in a custom Network Security Configuration.
The trigger is the app's target API level, not the operating system alone. For CT, an internal app behaves as before on Android 17 until its developers raise the target to 37. At that point the question is whether the app talks to servers with certificates from an internal CA, and whether the build excludes those domains. That fix lives in the app, not in the UEM, so it goes to whoever builds your in-house apps. The advice from our Android 17 webcast fits: test internal CAs and self-signed certificates before the rollout, and check your own apps.
Encrypted Client Hello (ECH) works along similar lines. For apps targeting Android 17, the system uses ECH for TLS connections when both the app's networking library and the server support it, which encrypts the server name in the handshake (Google, behavior changes). Oliver Schiemann and Magnus Wonschik therefore recommend bringing in the network team early and reviewing URL filters.
Two more changes for that team: for apps targeting Android 17, setContentCaptureEnabled(false) no longer disables Content Capture, and Google points to FLAG_SECURE for screens that must not be captured. And the local network permission below applies from the same target level.
Android 17 introduces the runtime permission ACCESS_LOCAL_NETWORK for apps that discover or talk to devices on the local network. For apps targeting API level 37 or higher, local network access is blocked by default until the permission is granted. Apps that target 36 or lower keep implicit access through the INTERNET permission (Google, local network permission).
The restriction sits deep in the networking stack. It covers outgoing and incoming TCP connections to local addresses, UDP unicast, multicast and broadcast, mDNS and SSDP discovery and the NsdManager class. The permission belongs to the NEARBY_DEVICES group, so users who have already granted another permission from that group are not asked again.
On managed devices you don't have to rely on the user tapping "allow". Google names setPermissionGrantState() as the way to pre-grant the permission for the apps that need it.
From Android 17, loopback traffic across profile boundaries, for example to 127.0.0.1, is no longer permitted by default (Google, behavior changes for all apps). Loopback within the same profile is unaffected. This applies to every app running on Android 17, regardless of its target API level.
If an app in the work profile talks to a local helper or proxy in the personal profile over localhost, that connection stops working with the update. Google frames the change as protection for corporate data.
Direct access to raw Human Interface Device data now needs the dangerous-level permission ACCESS_HID. On enterprise-managed devices, administrators can block that access by disabling USB data signalling with setUsbDataSignalingEnabled.
The same policy covers the new high-speed interfaces. Android 17 supports USB4 and Thunderbolt PCIe tunnelling, and Google states that these tunnels are blocked when USB data access is restricted. If you already disable USB data on corporate devices, the new interfaces fall under that setting.
The system Contacts Picker can now hand full contact records across profile boundaries, with the user selecting contacts one at a time. Whether work contacts are visible from the personal side is still governed by setCrossProfileContactsSearchDisabled, so an existing setting keeps its effect.
Not tied to Android 17, but also covered in the webcast: besides Owner and Admin, the zero-touch portal now has Manager, Assigner and Viewer roles (Google, zero-touch enrollment for IT admins). An Assigner can assign configurations without being able to change them. The speakers singled out the read-only Viewer role as useful for compliance documentation.
Google released Android 17 on 16 June 2026 for most supported Pixel devices and published the source code in the Android Open Source Project on the same day. Beyond Pixel, Google's announcement says to look for new devices running Android 17 "in the coming months".
Google defines the APIs and the new defaults. Your UEM vendor decides which of these policies the platform exposes and from which release. Your app developers decide the target API level and the network security configuration.
Behind the UEM question sits a shift that our Android 17 webcast covered in detail: away from the device policy controller that each UEM vendor has so far shipped as its own app, towards Google's Android Management API (AMAPI). The speakers advised following your UEM vendor's AMAPI roadmap. They showed the difference with the work profile: five steps and 5 to 10 minutes with the vendor's agent app, three steps and 3 to 5 minutes with web-based enrollment and no app download. For the background on AMAPI, see our post Are You Ready for the Future of Android Device Management?
ISEC7 advises on, integrates and operates UEM platforms from several vendors as part of our endpoint management services. We are an authorised Google Chrome Service Partner and Android Enterprise Service Provider. For teams building up Android know-how, our one-day Android Enterprise Fundamentals training covers management modes, provisioning and UEM integration, virtually or in Hamburg. For fleets running Samsung Knox, there is also the Samsung Knox Fundamentals course.
Yes. Google blocks AI agent automation inside work profiles by design. On fully managed devices and in the personal profile of COPE devices, administrators can disable AI automation entirely with the existing setNearbyAppStreamingPolicy. Device data for on-device agents via App Functions can be switched off globally with setAppFunctionsPolicy and the flag APP_FUNCTIONS_DISABLED.
Apps that target API level 37 or higher have Certificate Transparency enabled by default. Google warns that connections relying on private or internal certificates may fail unless those domains are opted out in a custom Network Security Configuration. The fix sits in the app build, so the app developers make it, not the UEM administrators.
Yes. Apps that target API level 37 or higher need the runtime permission ACCESS_LOCAL_NETWORK to reach devices on the local network. On managed devices, administrators can pre-grant it with setPermissionGrantState() so users are not prompted. Apps targeting API level 36 or lower keep implicit access through the INTERNET permission.
The block on cross-profile loopback traffic. From Android 17, traffic to addresses such as 127.0.0.1 between the work profile and the personal profile is no longer permitted by default. Loopback within the same profile keeps working. The change applies to every app running on Android 17, whatever API level it targets.